So we had an interesting problem on the office network the other day, thought it would be useful to write up in case someone else has this issue in the future, or more likely, I’ll have this same problem again and I’ll find my own blog after hours of googling with the fix. But I digress…
Our office internet connection is provided by the shared office space company, but is basically a standard LAN. So you connect anything to the “Internet” port, it gets a LAN IP address (In our case a 172.16 address). For most small businesses, this is quite fine as they don’t have domain controllers, servers etc, they just want Office365 and an internet connection.
So we used to have a Pfsense box, that NAT’d our office and then connected to the internet via the office port, in essence, a Double-NAT situation. This all worked fine, until we wanted something inbound, so we set up an OpenVPN connection, Pfsense being the client, to a company called VPNUK. The company gave us a static IP endpoint on the other end of the tunnel for us to use.
So the idea was that any traffic could hit the static IP endpoint on the tunnel at VPNUK, the traffic would be sent via the VPN to the Pfsense box and then a port forward into the network. This worked perfectly for about three years, until we had to replaces the pfsense box with a Sophos XG appliance due to needing to meet a security accreditation. Not a problem we thought, We’ll just connect the Sophos XG up exactly like the Pfsense box was.
Oh how we were wrong…. Turns out the Sophos XG does not support an OpenVPN client, it only supports tunnels Via IPSec, we also weren’t sure about how to even deal with the traffic like pfsense previously handled it.
So, we ended up in a bit of a funky situation. We implemented the XG as the default gateway for all VLANs, then created a pfsense virtual machine.
The pfsense box had the “LAN” side connected into each one of our internal VLAN’s and then it’s WAN interface into the Sophos XG. The PFsense then connected to the OpenVPN provider and we thought, easy peasy! Except for one quite large problem..
When the traffic from the openvpn IP came in, this is what happened:
Now, the problem with this, is that the Sophos XG, right at the end of the chain, had no state for the traffic hitting it. So it rejected the stream with “INVALID_TRAFFIC”. The traffic coming in, has to leave back out through the Pfsense box. What was happening here, was the server was routing it all back out through the default gateway, which in most cases would be the PF, but in our case was the XG.
So, we thought we would end up with two rather strange situations out of this, Pfsense between the XG and the “Internet”, thusly creating a triple nat scenario, or a “bridge”. OR working out how to send the traffic back to the originator, via Pfsense.
We opted for the latter, and discovered a very handy article from 7 years ago with this information:
So, we created a port forward rule to test this out.
and then disabled automatic outbound NAt rule generation, created the relevant mappings, as well as the mapping as mentioned on the above screenshot for the LAN interface. Like so:
as you can see, we did it for the entire subnet, not like the specifc host/service like mentioned above.
Tested it and it all works now!