Tunnel to Tunnel routing with between tunnel NATing

Started by Marvin, August 18, 2020, 04:00:26 AM

Previous topic - Next topic
August 18, 2020, 04:00:26 AM Last Edit: August 18, 2020, 04:05:28 AM by Marvin
We have a unique vpn scenario that i would like to see if i can get OPNsense to perform in order to replace an old system that has been doing this for years (but is no longer supported or update-able).

This system uses only one wan interface (vtnet0).  It runs 2 IPSec tunnels, routes traffic between them with NAT.  One tunnel connects to a customer that insists on their remote side to be 10.0.0.0/8 and the devices we connect to are very non-contiguous.  Obviously that 10.0.0.0/8 conflicts not only with our internal network structure but also conflicts with other customer VPN NATing we must do.

So our solution has been (for many years) to run a separate VPN device that only serves this customer.  One IPSec tunnel to that customer with their 10.0.0.0/8 and one IPSec tunnel to our main system configured as we need it to be.  Then the traffic is NATed, in some cases individual IP to individual IP.  And in others cases, entire subnet to entire subnet (of similar size -- what i believe OPNsense calls bitmask).  Then passed between the tunnels.

I have attempted to replicate this setup with OPNsense.  I can get both IPSec tunnels to run.  But i cannot get traffic NAT properly and route to the other tunnel.  All ports are unchanged, only the IPs are mapped.  Here is a very simplified drawing:
IPSec to us                                NATing                                                      IPSec to them
(local)                                                                                                        (remote)
172.100.1.0/24      <===>    172.100.1.0/24 <-> 192.168.100.0/24 <===> 192.168.100.0/24
(remote)                                                                                                    (local)
172.200.10.32/28    <===>      172.200.10.34 <-> 10.1.30.17   <===>     10.0.0.0/8
                                                172.200.10.35 <-> 10.1.42.6
                                                172.200.10.36 <-> 10.8.98.16

Also, with our old system, i could run tcpdump on each individual IPSec tunnel so it was easy to see what was going through each.  It appears that on OPNsense the IPSec tunnels are lumped together in a single dev interface, is that right?

Any help with this would be appreciated.  Let me know if additional data would be useful.

September 24, 2020, 07:45:51 AM #1 Last Edit: September 24, 2020, 07:52:12 AM by bitfinity-nl
Hi Marvin, I have a similer situation, only I have on one site "A" a direct connection and on site "B" a NAT connection.

I followed the documentation as descripted but I can't get any traffic through from site "A" to "B"  except icmp and ssh (if it not breaks).

From site "B" to "A" its no issue, everything works as expected. So I thinks it's a problem IPSec/NAT bug ??

Dit you resolved the issue?


Quote from: bitfinity-nl on September 24, 2020, 07:45:51 AM
Hi Marvin, I have a similer situation, only I have on one site "A" a direct connection and on site "B" a NAT connection.

I followed the documentation as descripted but I can't get any traffic through from site "A" to "B"  except icmp and ssh (if it not breaks).

From site "B" to "A" its no issue, everything works as expected. So I thinks it's a problem IPSec/NAT bug ??

Dit you resolved the issue?

Can you open a new thread with your own IP networks and add screenshots of P1, P2 and one-to-one NAT

Quote from: Marvin on August 18, 2020, 04:00:26 AM
We have a unique vpn scenario that i would like to see if i can get OPNsense to perform in order to replace an old system that has been doing this for years (but is no longer supported or update-able).

This system uses only one wan interface (vtnet0).  It runs 2 IPSec tunnels, routes traffic between them with NAT.  One tunnel connects to a customer that insists on their remote side to be 10.0.0.0/8 and the devices we connect to are very non-contiguous.  Obviously that 10.0.0.0/8 conflicts not only with our internal network structure but also conflicts with other customer VPN NATing we must do.

So our solution has been (for many years) to run a separate VPN device that only serves this customer.  One IPSec tunnel to that customer with their 10.0.0.0/8 and one IPSec tunnel to our main system configured as we need it to be.  Then the traffic is NATed, in some cases individual IP to individual IP.  And in others cases, entire subnet to entire subnet (of similar size -- what i believe OPNsense calls bitmask).  Then passed between the tunnels.

I have attempted to replicate this setup with OPNsense.  I can get both IPSec tunnels to run.  But i cannot get traffic NAT properly and route to the other tunnel.  All ports are unchanged, only the IPs are mapped.  Here is a very simplified drawing:
IPSec to us                                NATing                                                      IPSec to them
(local)                                                                                                        (remote)
172.100.1.0/24      <===>    172.100.1.0/24 <-> 192.168.100.0/24 <===> 192.168.100.0/24
(remote)                                                                                                    (local)
172.200.10.32/28    <===>      172.200.10.34 <-> 10.1.30.17   <===>     10.0.0.0/8
                                                172.200.10.35 <-> 10.1.42.6
                                                172.200.10.36 <-> 10.8.98.16

Also, with our old system, i could run tcpdump on each individual IPSec tunnel so it was easy to see what was going through each.  It appears that on OPNsense the IPSec tunnels are lumped together in a single dev interface, is that right?

Any help with this would be appreciated.  Let me know if additional data would be useful.

To capture encrypted traffic you can just do tcpdump on interface enc0. This is usually enough and in your case 100% enough. First check if traffic really get natted, also check if your Phase2 has SPD entries set.