IPSec VPN stops external communication

RouterOS General
1

I’ve configured an IPSec VPN to go between an RB450 and a 3rd-party router. When the tunnel is brought up, the routerboard stops communicating with anything outside of the VPN.

General config synopsis:

    • ether1 has a static IP of 10.0.1.1/32 and serves DHCP on the 10.0.1.0/24 subnet.
  • ether5 has a static IP given to it by our ISP’s DHCP reservation. For the sake of this thread, we’ll pretend the IP address is 5.5.5.5
  • the 3rd-party router has a private NATed subnet behind it of 192.168.24.0/24

When the tunnel was down, I could connect to the RB450 using the external IP address from my home machine (not within the VPN at all). From within the VPN there was no connectivity (because the tunnel was down).

Having brought the tunnel up, I can now connect to the RB450 using the internal 10.0.1.1 IP address, over the VPN, but now I can’t contact the external 5.5.5.5 IP address from my computer at home. No ping replies, no SSH access.

If I SSH in through the VPN, I can reboot the router.

Letting a ping run on 5.5.5.5 and a simultaneous ping run on 10.0.1.1, I notice the router come online on 5.5.5.5 first, and then after four or five replies I notice 5.5.5.5 stops responding and 10.0.1.1 starts responding, indicating that the VPN has been re-established.

What’s even more interesting is that with the VPN up, I’m able to connect to the SSH administration console on the RB450 to issue commands, but when I’m on the console and ping addresses on the 192.168.24.0/24 subnet (including the IP address of the machine I’m using to connect to the RB450 via 10.0.1.1) I get no ping replies.

So, why would the RB450 stop communicating with the world outside of its VPN tunnel? And why would I be able to connect to the administration console but not be able to ping the very machine that is connected?

I’m guessing the answers have something to do with routing, so here’s my routing table (pretending that the external IP address of the rb450 is 5.5.5.5):

[admin@rb450] > ip route print detail
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 
 0 ADS  dst-address=0.0.0.0/0 gateway=5.5.5.254 interface=ether5 
        gateway-state=reachable distance=0 scope=30 target-scope=10 
## Gateway is given to the RB450 by the ISP's DHCP

 1 ADC  dst-address=10.0.1.0/24 pref-src=10.0.1.1 interface=ether1 distance=0 
        scope=200 

 2 ADC  dst-address=10.0.2.0/24 pref-src=10.0.2.1 interface=ether2 distance=0 
        scope=200 

 3 ADC  dst-address=10.0.3.0/24 pref-src=10.0.3.1 interface=ether3 distance=0 
        scope=200 

 4 ADC  dst-address=10.0.4.0/24 pref-src=10.0.4.1 interface=ether4 distance=0 
        scope=200 

 5 A S  dst-address=192.168.24.0/24 gateway=ether5 interface=ether5 
        gateway-state=reachable distance=10 

 6 ADC  dst-address=5.5.5.0/23 pref-src=5.5.5.5 interface=ether5 
        distance=0 scope=10 
## The external IP address given to the RB450 by the ISP, 5.5.5.5, has a 23-bit subnet mask
2

5 A S dst-address=192.168.24.0/24 gateway=ether5 interface=ether5
gateway-state=reachable distance=10

Gateway should be ip address not the interface.

What is your IPsec configuration?

3

I’ve tried with the IP address as the gateway instead of the interface, same results.

IPSec config (still pretending that the RB450’s internet IP is 5.5.5.5 and the 3rd party router’s internet IP is 4.4.4.4):

[admin@rb450] /ip ipsec> peer print
Flags: X - disabled 
 0   address=4.4.4.4/32:0 auth-method=pre-shared-key 
     secret=<our_key> generate-policy=yes exchange-mode=main 
     send-initial-contact=yes nat-traversal=yes proposal-check=obey 
     hash-algorithm=sha1 enc-algorithm=aes-128 dh-group=modp1024 lifetime=8h 
     lifebytes=0 
[admin@rb450] /ip ipsec> proposal print
Flags: X - disabled 
 0   name="default" auth-algorithms=sha1 enc-algorithms=aes-128 lifetime=30m 
     pfs-group=modp1024 
[admin@rb450] /ip ipsec> policy print
Flags: X - disabled, D - dynamic, I - inactive 
 0 D src-address=0.0.0.0/0:any dst-address=0.0.0.0/0:any protocol=all 
     action=encrypt level=require ipsec-protocols=esp tunnel=yes 
     sa-src-address=5.5.5.5 sa-dst-address=4.4.4.4 proposal=default 
     priority=0 
## Note that the policy is dynamically created

And here’s my NAT table:

[admin@AviaRB] /ip> firewall nat print
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=srcnat action=masquerade out-interface=ether5
4

How exactly do you want your VPN tunnel to behave? Should it connect two internal subnets? Why parameter generate-policy is set to yes? Why both src-address and dst-address are set to 0.0.0.0/0:any?

5

Precisely. I need everything on the 10.0.1.0/24 subnet to be able to communicate with everything on the 192.168.24.0/24 subnet.

Seemed like the logical choice.

Those are dynamically generated because of the ‘generate-policy=yes’ parameter.

So having had these questions raised, I tried creating a policy manually, copying it from the dynamic policy, and setting ‘generate-policy=no’ for the peer.

Rebooted the rb450, still only able to connect to the RB450 through the VPN, and still unable to ping the 192.168.24.0/24 subnet from the RB450.

Here’s a representation of what’s going on:

VPN: [192.168.24.80/32(my_desktop_at_work)] ---> [3rd_party_router] ---> [ISP_1: 4.4.4.4] ---> (internet, across VPN) ---> [ISP_2: 5.5.5.5] ---> [rb450(ether5)]

External: [my_home_computer] ---> [ISP_3: 6.6.6.6] ---> (internet, without vpn) ---> [ISP_2: 5.5.5.5] ---> [rb450]

192.168.24.80 is able to connect remotely to the rb450 for administration, over the VPN, using any of the IP addresses on the 10.0.1.0 network (ether1 through ether4 on the rb450 are configured as 10.0.1.1 through 10.0.1.4) but once I’m connected to the rb450, it gets no ping replies from 192.168.24.80 (the very computer that is connected to the rb450).

My home computer is unable to ping the rb450 using 5.5.5.5 (though with the VPN disabled, my computer can ping 5.5.5.5 and can connect to the rb450 via ssh… as soon as the tunnel is brought up, external connectivity is lost).

6

If you set peer to generate policy automatically, other end should have static policy anyway.
In your case if you know that remote peers address is constant and you know for sure what private networks should be reached, then logical choice would be static policy on both ipsec routers.

And one more thing if masquerade is on the same router where ipsec is configured, then nat-traversal is not necessary, but traffic going through ipsec tunnel must not be masqueraded.
So to make this work you have to add one more nat rule above the masquerade rule.
For example:
/ip firewall nat
add dst-address=192.168.24.0/24 chain=srcnat action=accept

7

I’ve added the rule you described above but that seems to be making anti-progress:

Before adding the extra nat rule, I could reboot the rb450 and it would start responding to pings from external addresses, then after 4 or 5 pings it would stop responding externally and start responding over the VPN.

Having added the extra nat rule, it now doesn’t respond to external pings at all. Once the VPN is re-established it responds to pings over the VPN.

Rebooted and still can’t connect externally, still can’t ping anything on the 192.168.24.0/24 subnet.

Haven’t changed any other config, here’s my nat table now:

[admin@rb450] > ip firewall nat print   
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=srcnat action=accept dst-address=192.168.24.0/24 

 1   chain=srcnat action=masquerade out-interface=ether5
8

(bump)

9

(bump)

I hope bumping isn’t against any board policies or anything.. Just don’t want this to fall to the wayside.

10

try to configure as shown in this article:
http://wiki.mikrotik.com/wiki/MikroTik_router_to_CISCO_PIX_Firewall_IPSEC

11

The only thing in that configuration that differs from my configuration is that the policy has specific IPs set for the src-address and dst-address, whereas my configuration has the IPs set as 0.0.0.0/0:any for both (though the sa-src-address and sa-dst-address are set to the actual IPs in my configuration).

I tried setting the src-address and dst-address to the IP addresses used in sa-src- and sa-dst-address but it produced the same results.

12

(bump)