VPN NAT return problem
-
Over the last few days I've been attempting to get to the point where my (home, as a test for commercial deployment) firewall has a VPN to a cloud Linux instance (Linode in this case), and I can effectively treat the firewall's VPN IP address as if it were a public IP for the purposes of NATing. The Linux system translates back and forth between it's own public IP and the VPN, and the firewall handles outbound NAT via policy as well as selective inbound port forwarding. The goal is to allow a FreePBX system behind the firewall to act as if it came from a single IP, even though the site has multiple WAN connections.
(FreePBX in particular has a significant problem with multiWAN environments when dealing with certain providers like Twilio, because FreePBX can only send one "external" IP in the Contact header, and such providers blindly following it to send ACKs even if the firewall has failed over to an alternate connection and the entire rest of the SIP convo is happening on the other IP.....)
I'm hoping the following diagram depicts the situation and problem well enough:
I can get the setup fully operational ("temp") if I include a POSTROUTING rule on the Linux side, which converts the entire TCP session so that it looks like it's strictly going between the VPN server (Linux) and client (pfSense). However, this eliminates the ability to perform either selective forwarding based on source IP (there's a lot of SIP attacks out there), or have the FreePBX machine do any intrusion detection other than that.
If I drop the POSTROUTING rule, the packets that traverse the firewall have the original source IP address of the VoIP provider (or attacker, or whatever), the SYN packet reaches the FreePBX and is responded to with a SYN/ACK, and that packet reaches the LAN interface of the firewall. The problem is that from there it does not get caught by the existing NAT state, and ends up getting sent out via NAT on the default gateway [group?], and of course being TCP is lost in the ether.
I don't know enough about the internals of the pfSense packet flow to be able to figure out what's going wrong here, unfortunately. I'm not sure if it's something to do with the routes that OpenVPN (client or server) is constructing, or if this might even be a bug of some kind...?
I'm hoping somebody has some clue what's going on and how to resolve it.
Thanks!!!
-
@omegahacker
I guess, a pass rule on the OpenVPN tab is applied to the incoming packets from the VPN remote site. Hence pfSense cannot apply the reply-to tag, because OpenVPN is an interface group in fact, so the gateway is not unique.To get the response packets routed back correctly, assign an interface to the VPN instance and enable it.
Then move over the pass rule from the OpenVPN tab to the new interface.If you have other OpenVPN instances running, which you need to pass traffic, ensure that there is no pass rule on the OpenVPN tab matching the FreePBX traffic!
E.g. if you're running an access server limit its pass rule to the tunnel network, or just assign an interface to it as well. -
@viragomann
I didn't go into detail on the pfSense config, but here's what I've got:OpenVPN Client:
Peer to Peer, tun
UDPv4 on failover GW group
No tunnel settings (networks, topology, no-routes, etc)Interface:
"VPN" associated with aforementioned client
Block private and bogons not setGateway:
Uses VPN interface
Monitor IP is 4.2.2.1, this does work
No other settingsFirewall rules:
LAN: per diagram, traffic from $PBX to gateway GW_VPN
VPN: Allow All
OpenVPN: also Allow AllNAT Forwards:
TCP/UDP to $VPN on SIP/RTP ports to $PBXNAT Outbound:
Hybrid Outbound
From $PBX NAT to VPN addressAdvanced settings:
Nothing off default -
@omegahacker said in VPN NAT return problem:
@viragomann
I didn't go into detail on the pfSense config, but here's what I've got:OpenVPN Client:
Peer to Peer, tun
UDPv4 on failover GW group
No tunnel settings (networks, topology, no-routes, etc)Interface:
"VPN" associated with aforementioned client
Block private and bogons not setGateway:
Uses VPN interface
Monitor IP is 4.2.2.1, this does work
No other settingsFirewall rules:
LAN: per diagram, traffic from $PBX to gateway GW_VPN
VPN: Allow All
OpenVPN: also Allow AllNAT Forwards:
TCP/UDP to $VPN on SIP/RTP ports to $PBXNAT Outbound:
Hybrid Outbound
From $PBX NAT to VPN addressAdvanced settings:
Nothing off defaultNice. But what should this tell me?
I didn't request that. -
You mentioned creating an interface specifically for the client and having a pass rule on it, and I realized that I hadn't specified in my original post that I had already done that.
Rather than drip-feeding the overall pfSense configuration details for you and any others, I simply dumped all the relevant bits [that I know of] in one go.
-
@omegahacker
The point is, that there is no pass rule on the OpenVPN tab, which matches to traffic from the remote site.
The same is true for floating rules. -
OK, I think I see what you're saying: the pass rule on the OpenVPN tab is taking precedence over the pass rule for the individual interface.
I tried it out, and IT WORKED!
I honestly never would have guessed that, and I'm not even remotely sure I understand why that would be the case. Given that the OpenVPN rule is a trivial pass, and the client interface also had the exact same rule (i.e. no gateway setting), wouldn't the interface's pass rule have the same effect (e.g. killing the return packet)? I thought I was looking at some kind of mismatch in the routing table caused by some OpenVPN server config, but I guess not....
I wonder, is there a diagram similar to this one for Linux that explains how pfSense+FreeBSD packet flow happens, and might give me some insight as to why this worked...?
THANK YOU!
-
@omegahacker
As I mentioned, it is due to the reply-to tagging is not happening if a pass rule on an interface group matches the incoming traffic.
OpenVPN is an interface group. It is generated automatically, when firing up an OpenVPN instance, be it a client or a server.The reply-to is needed to route response packets back to the proper non-default gateway.
The reply-to tagging is done by the firewall rule, which passes the traffic.However this requires that the interface is unique. Since rules on interface groups or floating rule can be applied to multiple interface, it isn't unique and the reply-to tagging is not done by such rules.
And yes, interface group and floating rules have priority over interface rules. Hence you have to care, that there is no pass rule matching the incoming traffic on a non-default gateway interface for proper routing back the respond packets.