I have successfully established a OVPN connection from my mobile to mikrotik gateway. Got an VPN internet IP from the defined pool.
My internal network is segregated into vlans, which is added to the bridge interface
OVPN server range is defined without vlan tagging and i dont see anyway to add to the bridge (so i assume it is not needed)
I am running hex POE.
I have tried doing a forward firewall rule with many variations but the traffic is not going into the internal network.
Hope for some assistance
Re: OVPN client unable to reach internal network
To get an assistance, you must provide useful information. See my automatic signature just below for a hint.
Re: OVPN client unable to reach internal network
below is my firewall rules
FYI: i also had push the route via the ovpn client profile
Code: Select all
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=accept chain=input dst-address=192.168.88.1 in-interface=ether5
add action=accept chain=input comment="VPN incoming" disabled=yes dst-address=\
<WANIP> dst-port=<port> in-interface=sfp1 protocol=tcp
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" disabled=yes protocol=\
icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=accept chain=forward comment="Allow INET_LAN to Internet" \
in-interface-list=INET_LAN out-interface-list=WAN
add action=drop chain=forward
add action=drop chain=input
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=\
out,none out-interface-list=WANRe: OVPN client unable to reach internal network
Bumping for assistance
Re: OVPN client unable to reach internal network
You've exported the part of configuration you assume to be related, but the issue is typically where you do not expect it. That's why my signature doesn't say /<some particular branch> export hide-sensitive but /export hide-sensitive.
e.g. here, the firewall rules you use refer to interface-list items, but you haven't provided the /interface list member part.
So again - post the complete configuration, and modify the information that might identify you or permit an attack to your device (if someone shows a broken firewall configuration and a public IP at the same time, it is an invitation for the bad guys), but in such a way that the modification doesn't break relationship between the elements of the configuration. As an example, only the prefix of an own address and a gateway address in a subnet should be modified, so that it is still clear that both are in the same subnet.
e.g. here, the firewall rules you use refer to interface-list items, but you haven't provided the /interface list member part.
So again - post the complete configuration, and modify the information that might identify you or permit an attack to your device (if someone shows a broken firewall configuration and a public IP at the same time, it is an invitation for the bad guys), but in such a way that the modification doesn't break relationship between the elements of the configuration. As an example, only the prefix of an own address and a gateway address in a subnet should be modified, so that it is still clear that both are in the same subnet.
Re: OVPN client unable to reach internal network
sorry, i have reexported and vet through again.
Hope the info below is enough.
Hope the info below is enough.
Code: Select all
# jul/21/2021 22:15:59 by RouterOS 6.47.1
# software id = 9WAC-9NWN
#
# model = 960PGS
/interface bridge
add admin-mac=HIDE auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether2 ] poe-out=off
set [ find default-name=ether3 ] poe-out=off
set [ find default-name=ether4 ] poe-out=off
/interface vlan
add comment=vlan13 interface=bridge name=Guest vlan-id=13
add comment=vlan14 interface=bridge name=IoT vlan-id=14
add comment=vlan11 interface=bridge name=MGMT vlan-id=11
add comment=vlan12 interface=bridge name=SNET vlan-id=12
/interface ethernet switch port
set 1 default-vlan-id=11 vlan-header=always-strip vlan-mode=secure
set 2 default-vlan-id=12 vlan-header=always-strip vlan-mode=secure
set 3 vlan-header=add-if-missing vlan-mode=secure
set 5 vlan-mode=secure
/interface list
add name=WAN
add name=ManagementNW
add name=INET_LAN
add include=INET_LAN name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=dhcp ranges=HIDE
add name=dhcp_pool1 ranges=HIDE
add name=dhcp_pool2 ranges=HIDE
add name=dhcp_pool3 ranges=HIDE
add name=dhcp_pool4 ranges=HIDE
add name=vpn ranges=192.168.17.101-192.168.17.110
/ip dhcp-server
add address-pool=dhcp disabled=no interface=ether5 name=defconf
add address-pool=dhcp_pool1 disabled=no interface=MGMT lease-time=10h name=\
dhcp1
add address-pool=dhcp_pool2 disabled=no interface=SNET lease-time=4h name=\
dhcp2
add address-pool=dhcp_pool3 disabled=no interface=Guest lease-time=1h name=\
dhcp3
add address-pool=dhcp_pool4 disabled=no interface=IoT lease-time=2h name=\
dhcp4
/ppp profile
add local-address=192.168.17.45 name=ovpn remote-address=vpn use-encryption=\
required
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
/ip neighbor discovery-settings
set discover-interface-list=ManagementNW
/interface ethernet switch vlan
add independent-learning=yes ports=switch1-cpu,ether2,ether4 switch=switch1 \
vlan-id=11
add independent-learning=yes ports=switch1-cpu,ether3,ether4 switch=switch1 \
vlan-id=12
add independent-learning=yes ports=switch1-cpu,ether4 switch=switch1 vlan-id=\
13
add independent-learning=yes ports=switch1-cpu,ether4 switch=switch1 vlan-id=\
14
/interface list member
add interface=MGMT list=ManagementNW
add interface=ether5 list=ManagementNW
add interface=MGMT list=LAN
add interface=SNET list=INET_LAN
add interface=Guest list=INET_LAN
add interface=IoT list=INET_LAN
add interface=sfp1 list=WAN
/interface ovpn-server server
set auth=sha1 certificate=server cipher=aes256 default-profile=ovpn enabled=\
yes port=8443 require-client-certificate=yes
/ip address
add address=HIDE comment=defconf interface=ether5 network=\
HIDE
add address=HIDE interface=MGMT network=HIDE
add address=HIDE interface=SNET network=HIDE
add address=HIDE interface=Guest network=HIDE
add address=HIDE interface=IoT network=HIDE
/ip dhcp-client
add comment=defconf disabled=no interface=sfp1
/ip dhcp-server lease
HIDE
/ip dhcp-server network
HIDE
/ip firewall address-list
add address=HIDE list="IoT VIP"
add address=HIDE list="SNET VIP"
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=accept chain=input comment="Allow vlan11 to contact Gateway" \
dst-address=HIDE in-interface=MGMT
add action=accept chain=input dst-address=HIDE in-interface=ether5
add action=accept chain=input comment="VPN incoming" dst-address=\
HIDE dst-port=8443 in-interface-list=WAN protocol=tcp
add action=accept chain=input comment="defconf: accept ICMP" disabled=yes \
protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
disabled=yes in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=accept chain=forward comment="Allow INET_LAN to Internet" \
in-interface-list=INET_LAN out-interface-list=WAN
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=input
add action=drop chain=forward
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
/ppp secret
add name=ws profile=ovpn service=ovpnRe: OVPN client unable to reach internal network
OK. Now please post the export of firewall filter rules alone, but including the rule you tried to add in order to let the OVPN client connect to the individual subnets/VLANs. When looking at your rules, I have a feeling that you haven't completely grasped how they work, but I may be wrong.
Re: OVPN client unable to reach internal network
Hi Sindy,
I have added one more rule below the VPN input rule as such
I realised this is too risky and at the same time, i looked at the logs and it seems to bypass the NAT or some sort.
Yes, i am still not very familiar with mikrotik devices.
If there are wrong, insecure configs, please feel free to point out.
I have added one more rule below the VPN input rule as such
Code: Select all
add action=accept chain=input comment="VPN incoming" dst-address=HIDE \
dst-port=8443 in-interface-list=WAN protocol=tcp
add action=accept chain=forward comment="VPN to SNET" disabled=yes \
in-interface-list=WAN log=yes log-prefix=WAN2SNET out-interface=SNETYes, i am still not very familiar with mikrotik devices.
If there are wrong, insecure configs, please feel free to point out.
Re: OVPN client unable to reach internal network
OK, so maybe start from reading this post, and also have a look at the packet flow diagram to find out what are the roles of the input and forward chains. And also google something regarding the concept of a stateful firewall and the role of the connection tracking and the connection-state property in it. Then come back if that is not enough for you to reach your goal.
Re: OVPN client unable to reach internal network
My understanding is that input is for incoming to an interface (physical or logical) while forward is to pass on the packet to the next interface (assuming mikrotik is a member of that interface/network and it knows where to pass on to)
Upon reading the links you gave, i couldnt pick up where in my config is incorrect.
Can you more specifically point out the problem?
Or is there an article abt ovpn interface i need to read up on?
Upon reading the links you gave, i couldnt pick up where in my config is incorrect.
Can you more specifically point out the problem?
Or is there an article abt ovpn interface i need to read up on?
Re: OVPN client unable to reach internal network
When setting up VPN it will be not tied to any bridge. That will be routed interface. Maybe you have added vlan interfaces (not talking about vlan itself but interface) to the bridge then it may behave odd. You add vlans into the bridge, but vlan interfaces are routed interfaces not tied to bridge. In such config it is possible to route traffic between interfaces including ISP interface. All is about properly creating interfaces in relation to bridge. If you will mess it up micortik will not route traffic between routed interfaces such as VPN interface. It does not matter what iptables rule you will create it will be lost in the way how IPs are configured on the interfaces.
bridge (1.1.1.1/24) ---- (tag 10,20, untag 1) ----+-- VLAN 10
|
+- VLAN 20
vlan-10-int (2.2.2.1/24)
valn-20-int (3.3.3.1/24)
ppp0-vpn (1.2.3.4/24)
this is how it should be configured - more or less. If you will be adding or tying vlan interfaces (vlan-10-int and/or vlan-20-int) to the bridge then routing wise it will create artifical virtual router within the bridge that cannot be reached by by any external interface. meaning don't do this:
bridge (1.1.1.1/24) ---- (tag 10,20, untag 1) ----+-- VLAN 10
|
+-- VLAN 20
|
+--vlan-10-int (2.2.2.1/24)
|
+--valn-20-int (3.3.3.1/24)
ppp0-vpn (1.2.3.4/24)
Even if you will remove IP from the bridge it still wont work as the bridge is routed interfaces, but now it will be without IP. Obviously internal networks will work, but nothing that is outside the bridge like VPNs.
bridge (1.1.1.1/24) ---- (tag 10,20, untag 1) ----+-- VLAN 10
|
+- VLAN 20
vlan-10-int (2.2.2.1/24)
valn-20-int (3.3.3.1/24)
ppp0-vpn (1.2.3.4/24)
this is how it should be configured - more or less. If you will be adding or tying vlan interfaces (vlan-10-int and/or vlan-20-int) to the bridge then routing wise it will create artifical virtual router within the bridge that cannot be reached by by any external interface. meaning don't do this:
bridge (1.1.1.1/24) ---- (tag 10,20, untag 1) ----+-- VLAN 10
|
+-- VLAN 20
|
+--vlan-10-int (2.2.2.1/24)
|
+--valn-20-int (3.3.3.1/24)
ppp0-vpn (1.2.3.4/24)
Even if you will remove IP from the bridge it still wont work as the bridge is routed interfaces, but now it will be without IP. Obviously internal networks will work, but nothing that is outside the bridge like VPNs.
Re: OVPN client unable to reach internal network
hi lis, i am not sure if i got you correctly.
I assume you are saying i have created Interface > vlan when i should have done bridge > vlan.
If my understanding is right, what i have to do now is just to go to Bridge > Vlan and create all the vlans?
I dont think i am going to redo my network just for a VPN.
I assume you are saying i have created Interface > vlan when i should have done bridge > vlan.
If my understanding is right, what i have to do now is just to go to Bridge > Vlan and create all the vlans?
I dont think i am going to redo my network just for a VPN.
Re: OVPN client unable to reach internal network
ok i have managed to solve the problem.
since i have done most of my config as an INTERFACE, i created a OVPN server binding INTERFACE.
allowed it in my firewall rule and all works now.
Not sure if it is the best way or not but please point it out if it is not correct or not secure.
since i have done most of my config as an INTERFACE, i created a OVPN server binding INTERFACE.
allowed it in my firewall rule and all works now.
Not sure if it is the best way or not but please point it out if it is not correct or not secure.
Re: OVPN client unable to reach internal network
Matching traffic by interface is a tiny bit more secure than matching it by IP address, because the source address can be spoofed, and some attacks may possibly not need a response.
But no matter which packet property you choose for matching, the key was to place the rule at the proper position in the proper chain.
But no matter which packet property you choose for matching, the key was to place the rule at the proper position in the proper chain.
Re: OVPN client unable to reach internal network
Hi sindy,
as VPN internal traffic, i tried to do the firewall rule via IP matching.
i was monitoring the packet movement and the count was always 0.
i previously did forward source <xxx> to destinated vlan interface
<xxx>
i tried to use VPN client IP (coupled with another forward rule for VPN gateway IP) and VPN ip range <vpn ip/24> to a forward chain. both forwarded to the intended vlan interface.
this is the exact setup i have now, except the source interface now is the vpn binding interface.
so using IP in the firewall does not work.
separately, is this the most secure way to let external vpn cients hit the mirotik?
as VPN internal traffic, i tried to do the firewall rule via IP matching.
i was monitoring the packet movement and the count was always 0.
i previously did forward source <xxx> to destinated vlan interface
<xxx>
i tried to use VPN client IP (coupled with another forward rule for VPN gateway IP) and VPN ip range <vpn ip/24> to a forward chain. both forwarded to the intended vlan interface.
this is the exact setup i have now, except the source interface now is the vpn binding interface.
so using IP in the firewall does not work.
separately, is this the most secure way to let external vpn cients hit the mirotik?
Code: Select all
add action=accept chain=input comment="VPN incoming" dst-address=\
HIDE dst-port=8443 in-interface-list=WAN protocol=tcpRe: OVPN client unable to reach internal network
If you take the very same rule that now matches on in-interface=the-one-representing-that-client-tunnel and make it match on src-address=the.internally.assigned.ip.of.the.client instead, without moving it, it must work the same, otherwise there is a mistake in the IP address assigment. But that's only an exercise and a verification of the IP address configuration - matching on interface name is a bit safer as stated before.as VPN internal traffic, i tried to do the firewall rule via IP matching.
i was monitoring the packet movement and the count was always 0.
If you need to permit client connection(s) from anywhere in the internet, then yes, that's the maximum security a firewall rule can give you.is this the most secure way to let external vpn cients hit the mirotik?Code: Select alladd action=accept chain=input comment="VPN incoming" dst-address=\ HIDE dst-port=8443 in-interface-list=WAN protocol=tcp
Otherwise, you might want to add matching on a manually configured src-address-list if you don't need access from anywhere but just from a bunch of IP addresses known in advance. There's also a so-called port-knocking approach which adds an IP address to an address-list temporarily if the VPN client sends a few packets to particular port numbers arrive in particular order within a particular time interval before attempting to establish the VPN connection, but the actual improvement of security is not high.