Show Posts
1
19.7 Legacy Series / OPNsense does not route NAT'd packets through an IPSEC VPN
« on: January 21, 2020, 02:03:15 pm »
I'm struggling with this issue from nearly two weeks now and have tried to do every kind of debugging to have it working or, at least, to understand why the packets don't follow the kernel's IPSEC SA.
The use case scenario is quite straightforward:
192.168.25.0/26 <---> [ BARRACUDA ] 1.1.1.1 <-----> Internet <-----> 2.2.2.2 [ OPNSENSE ] <----> 192.168.26.0/24
Firewall A is a Barracuda firewall with a public IP of 1.1.1.1 and a LAN address of 192.168.25.62/26.
OPNSense has a public IP of 2.2.2.2 and a LAN IP 192.168.25.1/24. Address 192.168.25.1 is currently configured on OPNsense as a virtual IP on the loopback interface.
There's an IPSEC VPN tunnel between BARRACUDA and OPNSENSE where subnets 192.168.25.0/26 and 192.168.25.0/24 are routed. The IPSEC tunnel comes up and I can successfully:
1) Ping 192.168.25.62 from OPNSense, when I set the source IP address of 192.168.26.1.
2) Ping 192.168.26.1 from BARRACUDA
3) Even ping 192.168.26.1 from one of the hosts attached to BARRACUDA's LAN (let's say, host 192.168.25.1) when this host has the BARRACUDA set as its default gateway
Issues start to arise whenever I try to use OPNSENSE as a public gateway for clients behind BARRACUDA. For example let's say I want to forward incoming TCP connections on the OPNSENSE box on public IP 1.1.1.1 and TCP port 22 through the VPN tunnel to the destination host 192.168.25.1 TCP port 22.
To accomplish this, I would need two NAT operations, one for the source address and one for the destination address, then the packet is supposed to be routed through the VPN to the BARRACUDA, which will then forward it to the host on its LAN, but it does NOT and the packet doesn't even leave OPNsense.
First NAT: port forwarding
Interface: WAN
Source: any
Destination: 1.1.1.1 port 22
Translation address: 192.168.25.1 port 22
Second NAT: outbound NAT (manual)
Interface: WAN (or IPSEC, doesn't work either way)
Source: any
Destination: 192.168.25.1
Translation/target: 192.168.26.1 (VIP)
Firewall logs show both rule as being applied and packet successfully gets a destination IP of 192.168.25.1 and source IP 192.168.26.1 but from there nothing more happens.
What can I do to further debug the issue? Anybody got an idea of what could be the issue? Thanks a lot!!
The use case scenario is quite straightforward:
192.168.25.0/26 <---> [ BARRACUDA ] 1.1.1.1 <-----> Internet <-----> 2.2.2.2 [ OPNSENSE ] <----> 192.168.26.0/24
Firewall A is a Barracuda firewall with a public IP of 1.1.1.1 and a LAN address of 192.168.25.62/26.
OPNSense has a public IP of 2.2.2.2 and a LAN IP 192.168.25.1/24. Address 192.168.25.1 is currently configured on OPNsense as a virtual IP on the loopback interface.
There's an IPSEC VPN tunnel between BARRACUDA and OPNSENSE where subnets 192.168.25.0/26 and 192.168.25.0/24 are routed. The IPSEC tunnel comes up and I can successfully:
1) Ping 192.168.25.62 from OPNSense, when I set the source IP address of 192.168.26.1.
2) Ping 192.168.26.1 from BARRACUDA
3) Even ping 192.168.26.1 from one of the hosts attached to BARRACUDA's LAN (let's say, host 192.168.25.1) when this host has the BARRACUDA set as its default gateway
Issues start to arise whenever I try to use OPNSENSE as a public gateway for clients behind BARRACUDA. For example let's say I want to forward incoming TCP connections on the OPNSENSE box on public IP 1.1.1.1 and TCP port 22 through the VPN tunnel to the destination host 192.168.25.1 TCP port 22.
To accomplish this, I would need two NAT operations, one for the source address and one for the destination address, then the packet is supposed to be routed through the VPN to the BARRACUDA, which will then forward it to the host on its LAN, but it does NOT and the packet doesn't even leave OPNsense.
First NAT: port forwarding
Interface: WAN
Source: any
Destination: 1.1.1.1 port 22
Translation address: 192.168.25.1 port 22
Second NAT: outbound NAT (manual)
Interface: WAN (or IPSEC, doesn't work either way)
Source: any
Destination: 192.168.25.1
Translation/target: 192.168.26.1 (VIP)
Firewall logs show both rule as being applied and packet successfully gets a destination IP of 192.168.25.1 and source IP 192.168.26.1 but from there nothing more happens.
What can I do to further debug the issue? Anybody got an idea of what could be the issue? Thanks a lot!!