MikroTik

Community discussions
https://forum.mikrotik.com/

IPSec VPN is established, but traffic isn't sent through it

https://forum.mikrotik.com/viewtopic.php?t=130406

Page 1 of 1

IPSec VPN is established, but traffic isn't sent through it

Posted: Sat Feb 03, 2018 7:27 pm
by GregHill
I'm working on a setup that will eventually turn into a site-to-site VPN via the internet. For now it's a collection of "test lab" hardware all on one desk for easy testing. The topology is as shown in the attached image: one laptop connected to router A using the 10.0.84.0/24 network, one laptop connected to router B using the 10.0.85.0/24 network, the two routers linked together via a smart switch and using the 10.0.80.0/24 network. The smart switch and the laptop attached to it represent the internet; I've configured port mirror on the switch so that the attached T530 laptop can capture traffic between the two routers.
map.png
If I add the appropriate static routes (on A a route to 10.0.85.0/24 via gateway 10.0.80.1; on B a route to 10.0.84.0/24 via gateway 10.0.80.2) then all 4 devices (T420, Dell, router A, router B) can ping to every other device. When I run wireshark on the T530 it can see the unencrypted traffic between routers A and B.

Next step: encrypt the A-B link with IPsec. I remove those two static routes and set up IPsec peers, proposals, and policies.

/export from router A:
Code: Select all
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=testlab
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=10.0.84.1/24 interface=ether4 network=10.0.84.0
add address=10.0.80.2/24 interface=ether1 network=10.0.80.0
/ip ipsec peer
add address=10.0.80.1/32 dh-group=modp1024 enc-algorithm=aes-256 \
    hash-algorithm=sha256 local-address=10.0.80.2 nat-traversal=no secret=\
    bananapeels
/ip ipsec policy
add dst-address=10.0.85.0/24 level=unique proposal=testlab sa-dst-address=\
    10.0.80.1 sa-src-address=10.0.80.2 src-address=10.0.83.0/24 tunnel=yes
/system routerboard mode-button
set enabled=no on-event=""
/export from router B:
Code: Select all
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=testlab
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=10.0.80.1/24 interface=ether2 network=10.0.80.0
add address=10.0.85.1/24 interface=ether5 network=10.0.85.0
/ip ipsec peer
add address=10.0.80.2/32 dh-group=modp1024 enc-algorithm=aes-256 \
    hash-algorithm=sha256 local-address=10.0.80.1 nat-traversal=no secret=\
    bananapeels send-initial-contact=no
/ip ipsec policy
add dst-address=10.0.83.0/24 level=unique proposal=testlab sa-dst-address=\
    10.0.80.2 sa-src-address=10.0.80.1 src-address=10.0.85.0/24 tunnel=yes
/system routerboard mode-button
set enabled=no on-event=""
As you see they're very basic. No firewall, no NAT, no extra stuff connected, all static IP, no default routes, etc. Both routers have been reset without default config.

The IPsec seems to be connected fine: /ip ipsec remote-peers print shows established on both routers; /ip ipsec installed-sa print shows an SA for each direction.

The trouble is, every how-to I've read gets to this point and says "That's it! Traffic should pass through the link now." But when I try to ping from T420 or from router A to either 10.0.85.1 or 10.0.85.2 I'm told there's no route to host. Sure enough, there's nothing in the routing table for that. If I put my static routes back the pings go through but they're not encrypted; they go along side the VPN tunnel rather than through it.

What am I missing?

Re: IPSec VPN is established, but traffic isn't sent through it  [SOLVED]

Posted: Sat Feb 03, 2018 8:54 pm
by Sob
The answer is "routes". :)

If you don't have any, then e.g. router A only knows where to find 10.0.84.0/24 and 10.0.80.0/24. It has no idea where to look for 10.0.85.0/24.

Two directly connected routers are confusing for testing IPSec, because you're missing the usual internet between them. In order it to work, you have to set both routers as default gateway for each other. But then it's not immediately clear if traffic flows between LANs encrypted or not.

If you have third router, put it between those two and make it play the role of internet. If you don't, then you need to check IPSec statistics or look for ESP packets (protocol 50) on WAN interface to see if it works. Or you can block unencrypted traffic to other LAN using firewall filter.

Edit: Also your /ip ipsec policy config is wrong, it has .83 subnet, but according to image it should be .84.

Re: IPSec VPN is established, but traffic isn't sent through it

Posted: Sat Feb 03, 2018 9:12 pm
by cdiedrich
Do your routers have a default route?
This is needed because traffic to the desired peer has to be matched by a route.
Did you exclude the IPsec remote networks from NAT?
Create accept rules under /ip firewall nat for the corresponding subnets.

-Chris

Re: IPSec VPN is established, but traffic isn't sent through it

Posted: Sun Feb 04, 2018 12:29 am
by GregHill
Success! Sob and cdiedrich, thanks for your responses. I do have a third RB750G so I've configured it as "router C" between A and B to act as simulated internet. My expectation that the IPsec connection would add its own routing, or that a route for the far side of the IPsec is unnecessary because packets need to be encapsulated and then routed was wrong; I see now that one must already have routing to the remote subnet in place. The IPsec policy merely notices when traffic traveling an already-existing route matches its rules; when such traffic is found it is diverted through the IPsec.

For the benefit of any who may come along and read this thread later I'll give more detail about the test lab configuration that is now working.

The third router is physically located too far from my test bench, and it's "in production" as my real internet gateway, so please forgive me for using VLANs over a single physical link rather than plugging routers A and B into separate ports on C. It does add a bit of complexity. Here's the new topology:
map2.png
The /export from router A:
Code: Select all
/interface wireless security-profiles
  set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
  set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec proposal
  add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=testlab
/ip neighbor discovery-settings
  set discover-interface-list=!dynamic
/ip address
  add address=10.0.84.1/24 interface=ether4 network=10.0.84.0
  add address=10.0.60.2/24 interface=ether1 network=10.0.60.0
/ip ipsec peer
  add address=10.0.80.1/32 dh-group=modp1024 enc-algorithm=aes-256 \
    hash-algorithm=sha256 local-address=10.0.60.2 nat-traversal=no secret=\
    bananapeels
/ip ipsec policy
  add dst-address=10.0.85.0/24 level=unique proposal=testlab sa-dst-address=\
    10.0.80.1 sa-src-address=10.0.60.2 src-address=10.0.84.0/24 tunnel=yes
/ip route
  add distance=1 gateway=10.0.60.99
The /export from router B:
Code: Select all
/interface wireless security-profiles
  set [ find default=yes ] supplicant-identity=""
/ip hotspot profile
  set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec proposal
  add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=testlab
/ip neighbor discovery-settings
  set discover-interface-list=!dynamic
/ip address
  add address=10.0.80.1/24 interface=ether2 network=10.0.80.0
  add address=10.0.85.1/24 interface=ether5 network=10.0.85.0
/ip ipsec peer
  add address=10.0.60.2/32 dh-group=modp1024 enc-algorithm=aes-256 \
    hash-algorithm=sha256 local-address=10.0.80.1 nat-traversal=no secret=\
    bananapeels send-initial-contact=no
/ip ipsec policy
  add dst-address=10.0.84.0/24 level=unique proposal=testlab sa-dst-address=\
    10.0.60.2 sa-src-address=10.0.80.1 src-address=10.0.85.0/24 tunnel=yes
/ip route
  add distance=1 gateway=10.0.80.99
My router C config is pretty long. Here are the relevant parts of its /export:
Code: Select all
/interface vlan
  add interface=ether5 name=vlan60 vlan-id=60
  add interface=ether5 name=vlan80 vlan-id=80
/ip address
  add address=10.0.60.99/24 interface=vlan60 network=10.0.60.0
  add address=10.0.80.99/24 interface=vlan80 network=10.0.80.0
/ip route
  add distance=1 dst-address=10.0.84.0/24 gateway=10.0.60.2
  add distance=1 dst-address=10.0.85.0/24 gateway=10.0.80.1
Note that router C required some static routes. It has automatic/dynamic routes to subnets 10.0.60.0/24 and 10.0.80.0/24 because it has interfaces on those nets. It doesn't automatically know about 10.0.85.0/24 nor 10.0.84.0/24, and because router C is my real internet gateway, it has a default route to the internet. It would send traffic for the '84 and '85 subnets to the internet via that default route if I had not added static routes to tell it differently.

The light really came on for me in the testing. With the IPsec peers and policies disabled on routers A and B, a ping from T420 to Dell goes through unencrypted. Because of the port mirror configuration in the smart switch I could see the ping and its reply in the wireshark on T530. They had source and destination of 10.0.85.2 and 10.0.84.2.

When I enabled the IPsec peers and policies, pings failed for a few seconds (the policy grabbed the ICMP echo request, but the peering and SA weren't in place to carry it). Soon the routers finished establishing the connection and I began seeing pairs of ESP packets in wireshark. These had source and destination of 10.0.80.1 and 10.0.60.2. The pings are going through the tunnel!

With the routes configured so that traffic can find its way even if the IPsec tunnel is not in place I worried whether something might disrupt the IPsec and leave my packets in the open with me unaware of the problem. The suggestion to block unencrypted traffic with a firewall filter alleviates that concern.

Re: IPSec VPN is established, but traffic isn't sent through it

Posted: Sun Feb 04, 2018 4:38 am
by Sob
Wow, imagine if every newcomer to this forum was like you. You have nothing less than perfect score so far.

Regarding unencrypted traffic leaks, I suppose you found the "ipsec-policy" firewall matcher. It can be used to easily allow/block IPSec/non-IPSec traffic (which one you want depends on default action of your firewall - block/allow). It can be also used as handy shortcut for NAT exception (as mentioned by cdiedrich). That's what you didn't test yet, usually the router will have srcnat/masquerade. But as you found out, IPSec basically snatches outgoing packets that match policy and encrypts them. But srcnat happens before that and changed source address would no longer match the policy.

Re: IPSec VPN is established, but traffic isn't sent through it

Posted: Mon Feb 12, 2018 11:38 am
by kefealo
Hello,


I've in the same situation. But a bit stranger...
I don't know how to explain the situatioin, but... After I unboxed the router and connected to the LAN and the WAN, I ran the quick configuration on the router. I left enabled the PPTP for a temporary time (for the old users, compatibility reasons only and will be turned off. )
This time I experienced a strange thing. Sometimes, after I have a successful VPN connection, no traffic the from/to VPN client I don't know why.
Here is an example:
Code: Select all
        rx-packets-per-second:               0
           rx-bits-per-second:            0bps
     fp-rx-packets-per-second:               0
        fp-rx-bits-per-second:            0bps
          rx-drops-per-second:               0
         rx-errors-per-second:               0
        tx-packets-per-second:               0
           tx-bits-per-second:            0bps
     fp-tx-packets-per-second:               0
        fp-tx-bits-per-second:            0bps
          tx-drops-per-second:               0
    tx-queue-drops-per-second:               0
         tx-errors-per-second:               0
But the other VPN connections working properly. What I missed? Have to know, I'm a newcomer to the Mikrotik world. Any comment will be appreciated!
The only thing that I changed, the LAN address and added the missing L2TP and IPSec rules.

Re: IPSec VPN is established, but traffic isn't sent through it

Posted: Thu Feb 28, 2019 2:26 pm
by voljka
Note that router C required some static routes. It has automatic/dynamic routes to subnets 10.0.60.0/24 and 10.0.80.0/24 because it has interfaces on those nets. It doesn't automatically know about 10.0.85.0/24 nor 10.0.84.0/24, and because router C is my real internet gateway, it has a default route to the internet. It would send traffic for the '84 and '85 subnets to the internet via that default route if I had not added static routes to tell it differently.
1) Why do you need routes to your PRIVATE LANs on router C, what in your case acts as Internet?
2) Does anybody has working example how to get LAN traffic pass through IPSEC tunnel between two Mikrotiks, connected via direct cable? So no router C at all?
All times are UTC+02:00
Page 1 of 1
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/