IPSec joining two subnets fail

ax25 · Fri Feb 17, 2023 4:52 pm

Hi all,

I'm having (probably trivial) problem of setting up a site-to-site VPN via IPSec. I want to join 192.168.10.0/25 AND 192.168.10.128/25 (each with their own DHCP and clients) into one 192.168.10.0/24. I have some static leases which I want to be available for everyone.

IPSec and generic firewall settings are ommited, since I've got tunnel running. Firewall NAT contains only SNAT rule and MASQUERADE one as a second priority.

Config site A

/ip address
add address=192.168.10.128/24 interface=vlan1
/ip pool
add name=main_pool ranges=192.168.10.129-192.168.10.254
/ip dhcp-server
add address-pool=main_pool interface=vlan1 lease-time=1m name=main
/ip dhcp-server network
add address=192.168.10.128/24 dns-server=192.168.10.128 gateway=192.168.10.128
/ip ipsec policy
add dst-address=192.168.10.0/25 peer=peer1 proposal=proposal1 src-address=192.168.10.128/25 tunnel=yes
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.10.0/25 log=yes src-address=192.168.10.128/25

Config site B

/ip address
add address=192.168.10.1/24 interface=vlan1
/ip pool
add name=main_pool ranges=192.168.10.2-192.168.10.127
/ip dhcp-server
add address-pool=main_pool interface=vlan1 lease-time=1m name=main
/ip dhcp-server network
add address=192.168.10.1/25 dns-server=192.168.10.1 gateway=192.168.10.1
/ip ipsec policy
add dst-address=192.168.10.128/25 peer=peer1 proposal=proposal1 src-address=192.168.10.0/25 tunnel=yes
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.10.128/25 log=yes src-address=192.168.10.0/25

The problem is, SNAT rules do not work. There's a ping between routers (192.168.10.1 and 192.168.10.128), so packets are flowing through the tunnel, but I cannot reach anything in the relevant subnet.

Can it be a routing problem? I've ran tcpdump on one of the machines inside network while trying to ping it from the other router, and I can see packet arriving, but there's no reply – I guess because there's no route or SNAT is broken:

dropped privs to pcap
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:14:19.093938 IP 192.168.10.128 > 192.168.10.13: ICMP echo request, id 57088, seq 0, length 36
01:14:20.155576 IP 192.168.10.128 > 192.168.10.13: ICMP echo request, id 57088, seq 256, length 36
01:14:21.197926 IP 192.168.10.128 > 192.168.10.13: ICMP echo request, id 57088, seq 512, length 36
01:14:22.280003 IP 192.168.10.128 > 192.168.10.13: ICMP echo request, id 57088, seq 768, length 36
01:14:23.336803 IP 192.168.10.128 > 192.168.10.13: ICMP echo request, id 57088, seq 1024, length 36

What am I doing wrong?

Sob · Fri Feb 17, 2023 5:47 pm

But why? You won't have L2 connectivity anyway. And if it's only L3, you might as well go with clean and simple separate subnets.

But if you insist, it should be possible. Currently you have problem on site A, because e.g. 192.168.10.200 has /24, so it thinks that even remote 192.168.10.10 is local. So it will send ARP request... and get nothing. You can either change subnet to /25 (but then the illusion of same subnet will go completely down the drain; in this case also better move gateway from .128, because for /25 it's network address, some devices may be able to use it, but not all) or add proxy ARP. For Proxy ARP to work, you'll need route to remote /25. Site B has /25 already, which is correct/wrong depending on how you look at it.

ax25 · Fri Feb 17, 2023 5:55 pm

Thanks for your answer @Sob. Could you elaborate on why I won't have L2 connectivity? Because there's no EoIP tunnel between sites? I already have proxy-arp enabled on both sites for the bridges vlan1 interfaces belong to, so I guess it should do it... my goal was to have "clean" connectivity, so traceroute across the subnet won't show intermediate hops in between, just increased packet travel time

Sob · Fri Feb 17, 2023 6:05 pm

Because IPSec carries only IP packets (= L3). You can have L2 with EoIP, but then you'll have to deal with different problems, at least some DHCP isolation would be required if each site should have own server. If you stick with IPSec, for proxy ARP to work, you'll need routes to remote sites. As for whether this part works correctly, don't guess, you know tcpdump, you can be sure. Btw, since router will be routing, traceroute will see it.

ax25 · Fri Feb 17, 2023 6:11 pm

Thank you. I'll proceed with routes and update on my progress

ax25 · Fri Feb 17, 2023 7:07 pm

Another dummy question – which route gateway should I use in this case (routing to remote subnet)? My bridge interface? Because if I add just Site router route becomes invalid and unreachable (which's obvious)

Sob · Fri Feb 17, 2023 8:01 pm

There are different levels. Routing needs a route (but in this case even default one is enough). With proxy ARP I'm not completely sure, there were some changes, possibly bugs, but route pointing to different interface than LAN should be sure bet. It's even possible that it's not needed and default one will be enough. Again, test it, tcpdump is your friend. IPSec doesn't care about routes at all, it will work even if it points somewhere completely wrong.

ax25 · Sun Feb 19, 2023 1:58 am

Thanks @Sob! I've got it working in the end – with separate subnets. However, I've got few blockers. So in case it'll help someone:

- Traceroute helps A LOT. In my case after I've made the move to separate subnets ping between endpoints broke, although tunnel was established with Phase 2. Package counters were showing zeroes, so policy was not being hit; traceroute helped clarify that packets were going via default route (and different interface), thus omitting the tunnel;
- I've added a route to desired site's subnet on each router, and everything started working;
- My subnets were on VLAN interfaces, and route works if you specify an interface of a source subnet as a gateway;
- Some devices in one of the subnets didn't have update route information from the router (or ARP info was missing?) – I could ping them (and see it via tcpdump) from different subnet, but replies could not reach initiator – because there was no route. Simple reboot or DHCP release/renew fixes it.

Sob · Mon Feb 20, 2023 12:00 am

Generally no extra routes should be needed, but it's possible that in your case they are, it depends on how everything is configured.

IPSec joining two subnets fail [SOLVED]

IPSec joining two subnets fail

Re: IPSec joining two subnets fail

Re: IPSec joining two subnets fail

Re: IPSec joining two subnets fail

Re: IPSec joining two subnets fail

Re: IPSec joining two subnets fail

Re: IPSec joining two subnets fail [SOLVED]

Re: IPSec joining two subnets fail

Re: IPSec joining two subnets fail

Who is online