HI all,
I usually configure ipsec VPNs between two mikrotiks without problems.
Now for the first time I have had to configure it with a PPPOE client WAN and NAT only works in one direction.
Scenario:
Mikrotik A
Ether1 194.XXX.XXX.XXX/29
Ether2 192.168.XXX.XXX/24
Mikrotik B
Ether1 WANPPPOE
Ether2 192.168.YYY.XXX/24
If I ping from B to A I arrive at the router and the LAN
If I ping A to B I get to the router but not the LAN
I can’t understand what’s blocking me.
Some advice?
Thanks in advance
No suggestions?
I connected other routers that I had available and I confirm that I continue to have the problem only towards the PPPOE.
Probably something in firewall. Perhaps somehow related to the fact that default config (without PPPoE) has WAN interface in WAN interface list, but manually added PPPoE interface is not there. Or something else, there are many possibilities. It’s hard to say without seeing it.
Hi Sob,
Thanks for the reply.
For my configurations I delete all the default rules and manually create what I need.
If I completely disable the firewall the situation does not change.
I have the same configurations on multiple routers and I don’t have this problem.
I have set up the vpn with more routers and the problem I keep having it only towards this PPPOE, I thought there might be something at the provider level, I used a PfSense and everything worked, so I am convinced that there is something that I am not doing correctly.
Do not forget to provide a source ip address with your ping. It is done in the “Advanced” button of the WinBox ping tool.
If you do not do this the router will use the WAN ip as the ping source address and the tunnel ping will of course fail !
VPN site to site tunnels work just fine over the standard Mikrotik default configuration (eth1=wan, eth2-5 bridged=LAN) which automatically privides exception rules für UDP500 traffic (ike) and ESP which are the IPsec components.
IKEv1 example can be found here:
https://administrator.de/contentid/564730
Unfortunately in German but the screenshots are pretty much self explaining.
An IKEv2 example here:
https://administrator.de/tutorial/ipsec-ikev2-standort-vpn-vernetzung-mit-cisco-pfsense-opnsense-und-mikrotik-544054.html#toc-11
Hi Sob,
sorry, you’re right.
interface
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ether1 ether 1500 1598 4074
1 RS ether2 ether 1500 1598 4074
2 RS ether3 ether 1500 1598 4074
3 RS ether4 ether 1500 1598 4074
4 S ether5 ether 1500 1598 4074
5 RS wlan1 wlan 1500 1600 2290
6 R WANPPPOE pppoe-out 1480
7 R bridgeLAN bridge 1500 1598
8 R vlanPPPOE vlan 1500 1594
ip address
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 ;;; LAN
192.168.5.1/24 192.168.5.0 bridgeLAN
1 D 194.XXX.XXX.XXX/32 195.XXX.XXX.XXX WANPPPOE
ip firewall nat
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; VPN_OF1_IN
chain=dstnat action=accept src-address=192.168.20.0/24 dst-address=192.168.5.0/24 log=no log-prefix=""
1 ;;; VPN_OF2_IN
chain=dstnat action=accept src-address=192.168.10.0/24 dst-address=192.168.5.0/24 log=no log-prefix=""
2 ;;; VPN_OF1_OUT
chain=srcnat action=accept src-address=192.168.5.0/24 dst-address=192.168.20.0/24 log=no log-prefix=""
3 ;;; VPN_OF2_OUT
chain=srcnat action=accept src-address=192.168.5.0/24 dst-address=192.168.10.0/24 log=no log-prefix=""
4 chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix=
ip firewall filter
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; VPN_OF1_IN
chain=forward action=accept src-address=192.168.20.0/24 dst-address=192.168.5.0/24 log=no log-prefix=""
1 ;;; VPN_OF2_IN
chain=forward action=accept src-address=192.168.10.0/24 dst-address=192.168.5.0/24 log=no log-prefix=""
2 ;;; VPN_OF1_OUT
chain=forward action=accept src-address=192.168.5.0/24 dst-address=192.168.20.0/24 log=no log-prefix=""
3 ;;; VPN_OF2_OUT
chain=forward action=accept src-address=192.168.5.0/24 dst-address=192.168.10.0/24 log=no log-prefix=""
4 chain=input action=accept protocol=icmp log=no log-prefix=""
5 chain=input action=accept protocol=udp dst-port=500 log=no log-prefix=""
6 chain=input action=accept protocol=udp dst-port=4500 log=no log-prefix=""
7 chain=input action=accept protocol=ipsec-ah log=no log-prefix=""
8 chain=input action=accept protocol=ipsec-esp log=no log-prefix=""
9 chain=input action=drop in-interface-list=WAN log=no log-prefix=""
ip route
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 WANPPPOE 1
1 A S 192.168.10.0/24 bridgeLAN 1
2 ADC 192.168.5.0/24 192.168.95.1 bridgeLAN 0
3 A S 192.168.20.0/24 bridgeLAN 1
4 ADC 195.XXX.XXX.XXX/32 194.XXX.XXX.XXX WANPPPOE 0
I have not added the IPSEC configuration but it is established.
I haven’t added the WAN LIST but PPPOE is present.
For lfoerster,
thank’s for reply.
In my ipsec configurations I use a static route to reach the VPN via the LAN bridge.
In random order:
- “/export hide-sensitive file=somename” would be better
- from this, it’s not your firewall, because it allows any traffic to pass though router, it doesn’t block anything at all
- what’s the point of routes to 192.168.10.0/24 and 192.168.20.0/24?
- pref-src 192.168.95.1 for 192.168.5.0/24 is weird, I don’t see how that happens (but it shouldn’t be breaking anything)
- you can try some logging, for example:
/ip firewall mangle
add chain=prerouting src-address=192.168.10.0/24 dst-address=192.168.5.0/24 protocol=icmp action=log
add chain=forward src-address=192.168.10.0/24 dst-address=192.168.5.0/24 protocol=icmp action=log
add chain=postrouting src-address=192.168.10.0/24 dst-address=192.168.5.0/24 protocol=icmp action=log
add chain=input src-address=192.168.10.0/24 dst-address=192.168.5.0/24 protocol=icmp action=log
Then if you ping 192.168.5.x from 192.168.10.x, you should see it in prerouting, and then either in input (if it’s 192.168.5.1) or in forward and postrouting.
Hi,
I answer by points
-
what’s the point of routes to 192.168.10.0/24 and 192.168.20.0/24?
I have always configured the vpn in this way and if I do not set the routes manually to the bridge they do not work. -
pref-src 192.168.95.1 for 192.168.5.0/24 is weird, I don’t see how that happens (but it shouldn’t be breaking anything)
My mistake, I probably touched a button unintentionally pref-src 192.168.5.1 for 192.168.5.0/24
I am attaching the exported file.
Below are the results of the logs.
01:34:49 firewall,info prerouting: in:WANPPPOE out:(unknown 0), src-mac b0:26:80:0b:60:9a, proto ICMP (type 8, code 0), 192.168.20.250->192.168.5.55, len 56
01:34:49 firewall,info forward: in:WANPPPOE out:bridgeLAN, src-mac b0:26:80:0b:60:9a, proto ICMP (type 8, code 0), 192.168.20.250->192.168.5.55, len 56
01:34:49 firewall,info postrouting: in:(unknown 0) out:bridgeLAN, src-mac b0:26:80:0b:60:9a, proto ICMP (type 8, code 0), 192.168.20.250->192.168.5.55, len 56
192.168.20.250 Is the remote router 192.168.5.55 is the computer in my lan.
mktexp.rsc (4.39 KB)
Those routes are not needed, it must work without them. They would make sense if they had pref-src=192.168.5.1, that would help with access to remote subnets from router itself. As they are now, they are useless.
The two dstnat rules are not needed either. Similar with the four filter rules in chain=forward, currently they don’t do anything, because default is action=accept, so what is accepted by these would be accepted anyway. But here it’s good idea to add proper firewall rules (see e.g. this) and then they can be useful.
Log shows packet that successfully passed through router and was sent to device in LAN. That’s what you want. You can add additional rules to log responses:
/ip firewall mangle
add chain=prerouting src-address=192.168.5.0/24 dst-address=192.168.10.0/24 protocol=icmp action=log
add chain=forward src-address=192.168.5.0/24 dst-address=192.168.10.0/24 protocol=icmp action=log
add chain=postrouting src-address=192.168.5.0/24 dst-address=192.168.10.0/24 protocol=icmp action=log
add chain=output src-address=192.168.5.0/24 dst-address=192.168.10.0/24 protocol=icmp action=log
But if the 192.168.5.55 doesn’t respond, then it’s its fault.
Hi Sob,
first of all I would like to thank you again for your support and for the time you are dedicating to me.
For more information, I made further tests.
You’re right, the ping problem was my computer’s firewall.
My defense has to say that the problem occurs to me only in my office and when I was in OF2 no, I probably did not use my computer for tests.
As this is a test environment I have few objects on the network and I assumed I was using my pc for ping.
The thing that further convinced me that there was a problem, is that the web browser pages in both OF1 and OF2 do not open to me from my office.
So the problem now changes from “the vpn doesn’t work” to “the vpn works but I can’t reach the web pages of the servers”
For example, I did other tests, in OF1 I have a Linux server with a web server on it, the web page does not respond while in SSH it does. Yesterday I was in OF2 and from there no problem.
As for the routes, I assure you that if I do not configure them in this way, the routes of the VPNs will not work but for the moment I do not think it is important.
From the end, if the routing table you posted before is complete, then I don’t see how those routes can be useful, or why it shouldn’t work without them. In a way, they are wrong, because they point to bridgeLAN, where those remote subnets definitely aren’t connected to. But this part doesn’t matter, because IPSec policies override routes.
I sometimes add such routes too, but I do it because I also have unreachable routes for whole 192.168.0.0/16 and friends, to block traffic to unconfigured subnets. My problem is that IPSec doesn’t add routes to remote subnets, but routing process needs some, otherwise it would see only my unreachable route and would drop packets. But in your case there’s no such problem, you have default route and it covers any destination, everything is reachable.
So if it really doesn’t work without these routes, there’s something weird going on. But I don’t see from your config what it might be.
As for the rest, if something doesn’t work, you need to find out where exactly it fails. Same way as with ping, use logging rules or packet sniffer, examine step by steps what is ok and what isn’t. It could be e.g. firewall on other routers or target devices (not on this one, it doesn’t block anything).
Hi,
after doing further tests, what I have verified is this: the VPN works but does not open the web server while I can reach it in SSH
The log looks like this on the destination router
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (SYN), 192.168.5.55:59295->192.168.20.10:80, len 52
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (SYN), 192.168.5.55:59295->192.168.20.10:80, len 52
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (SYN), 192.168.5.55:59296->192.168.20.10:80, len 52
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (SYN), 192.168.5.55:59296->192.168.20.10:80, len 52
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 40
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 40
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59296->192.168.20.10:80, len 40
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59296->192.168.20.10:80, len 40
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59295->192.168.20.10:80, len 590
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59295->192.168.20.10:80, len 590
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59295->192.168.20.10:80, len 596
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59295->192.168.20.10:80, len 596
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59295->192.168.20.10:80, len 606
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59295->192.168.20.10:80, len 606
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 52
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 52
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 60
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 60
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 68
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 68
10:24:09 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 76
10:24:09 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK), 192.168.5.55:59295->192.168.20.10:80, len 76
10:24:14 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,FIN), 192.168.5.55:59295->192.168.20.10:80, len 40
10:24:14 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,FIN), 192.168.5.55:59295->192.168.20.10:80, len 40
10:24:14 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59296->192.168.20.10:80, len 587
10:24:14 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,PSH), 192.168.5.55:59296->192.168.20.10:80, len 587
10:24:25 firewall,info prerouting: in:ether1 out:(unknown 0), src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,FIN), 192.168.5.55:59296->192.168.20.10:80, len 40
10:24:25 firewall,info postrouting: in:(unknown 0) out:bridge_LAN, src-mac 00:22:bd:f8:19:ff, proto TCP (ACK,FIN), 192.168.5.55:59296->192.168.20.10:80, len 40
the destination router has the same configuration as the one attached previously.
I searched the forum for some ideas but none of them worked.
For the route to the bridge, I verified that if I disable it, the vpn continues to work but I can no longer ping directly from the terminal of the mikrotik to the objects of the vpn lan.
The log shows only one direction, but even that is enough to tell that some bidirectional communication is happening. You can use packet sniffer on server, if you want to see more details. Or try one simple request using:
curl http://192.168.20.10
As for routes, that’s the thing I described about pref-src (which in your case would be your original routes with added pref-src=192.168.5.1). But now I see that I was a bit wrong, because when you point them to bridgeLAN, where 192.168.5.1 is assigned to, it has the same effect. Ooops. 