(IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP
-
@jimp do you have any ideas? I know in your guides/hangouts you said that interface address outbound NAT should work through the IPsec tunnel. I have this same setup with OpenVPN and it was working fine with or without outbound NAT (because it supports reply-to's).
-
Outbound NAT table looks good:
But then their states are closed. I'm assuming because of the no return packets issue.
-
If I create an outbound NAT rule in the IPsec interface in Site A from any of its local subnet to any device in the Site B's subnet and do a test trying to access the servers in Site B from Site A, the same exact behavior happens. The return traffic reaches the Site A tunnel interface but is somewhat dropped preventing return traffic from being able to reach the source. Why is this happening?
-
BUMP! Anybody please?
-
Anybody can help, please?
-
You can't outbound NAT like that on the IPSec interface the reply traffic will never hit it and will just get dropped. Which is what you're seeing.
If you need to NAT on IPSec it has to be done on the P2 policy but you can't do that for this situation because the source would have to be 'any'.
You can't do it with routed IPSec either becaise of no reply-to as you saw.
Use OpenVPN in a situation like that and you can port forward dircetly and use reply-to to avoid asymmetry.
Steve
-
@stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:
You can't outbound NAT like that on the IPSec interface the reply traffic will never hit it and will just get dropped. Which is what you're seeing.
If you need to NAT on IPSec it has to be done on the P2 policy but you can't do that for this situation because the source would have to be 'any'.
You can't do it with routed IPSec either becaise of no reply-to as you saw.
Use OpenVPN in a situation like that and you can port forward dircetly and use reply-to to avoid asymmetry.
Steve
But in your routed IPsec guide, it specifically says that outbound NAT to interface address works. Is that clause not supposed to be there then? Some references even say that the workaround to the reply-to issue for IPsec is outbound NAT, just like what I'm doing.
What is the reason why traffic gets dropped? The return traffic does get to the IPsec interface as seen in the packet capture but get dropped on that interface itself.
I switched from OpenVPN to IPsec because of the sole purpose of needing more bandwidth to saturate my 100Mbps link between the two sites. I'm only using an APU2C4 for pfsense on two sites and with OpenVPN, I'm only getting 50Mbps so that won't cut it.
-
-
Ah, sorry I missed you were using VTI here. You still can't do it by default as you found.
You can do outbound NAT from the tunnel subnet or from subnet routed over it. You can port forward to IPs a remopte subnet. You can't do it on the tunnel interfaces because the filtering does not parse traffic equally.
If you only have route based IPSec you could try setting those sysctls. They can be applied via System Tunables ion the GUI. It will break filtering for policy based tunnels though.
Steve
-
@stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:
Ah, sorry I missed you were using VTI here. You still can't do it by default as you found.
Yeah, I'm not using the traditional policy-based IPsec. I'm using routed VTI. I thought that's what you meant by "route based" IPsec in your earlier reply? Aren't those one and the same?
You can do outbound NAT from the tunnel subnet or from subnet routed over it. You can port forward to IPs a remopte subnet. You can't do it on the tunnel interfaces because the filtering does not parse traffic equally.
Sorry, what do you mean? Yes, I do have a port forward to a remote subnet like so:
When your documentation said that outbound NAT to interface address in the tunnel interface works, what does it mean? I mean, it does work like I showed, it does translate the original source IP to the tunnel interface address, but the problem is the return traffic doesn't get handled properly.
If you only have route based IPSec you could try setting those sysctls. They can be applied via System Tunables ion the GUI. It will break filtering for policy based tunnels though.
Steve
I already did try setting those and it breaks the normal site-to-site routing as I explained here. And yes, that workaround would've been perfect for me because I do not use policy based tunnels so no issues in that. But I can't make it work. With the workaround in place, I can't even do normal pings from any device on either either site to any device on either site.
-
Most of the port forward and outbound NAT rules that I have are posted here:
https://forum.netgate.com/post/953857
-
@stephenw10 Do you have any more ideas regarding this?
-
Yes, route-based IPSec is VTI,
No, you can't outbound NAT on a VTI interface because, as you found, the reply traffic will not be translated back.
You should use OpenVPN for this if you need to configure it as you have now.
Steve
-
@stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:
Yes, route-based IPSec is VTI,
No, you can't outbound NAT on a VTI interface because, as you found, the reply traffic will not be translated back.
You should use OpenVPN for this if you need to configure it as you have now.
Steve
I actually was using OpenVPN without any issues except for the fact that I upgraded my ISP subscription to 100Mbps and OpenVPN cannot saturate that bandwidth as my APU2C4 does not a powerful single-core performance. This is where IPsec comes in as it does saturate the whole 100Mbps between the two sites.
So my question now is, why do those sysctl workarounds not work for me? They would've been perfect because I'm not using policy-based IPsec.
-
Unclear. Check the firewall states that are created in each case at each end. Something is still mismatched I would suggest. Or not creating a state at all which should then show as blocked unless you have disabled logging default blocks or added your own block rule without logging.
-
@stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:
Unclear. Check the firewall states that are created in each case at each end. Something is still mismatched I would suggest. Or not creating a state at all which should then show as blocked unless you have disabled logging default blocks or added your own block rule without logging.
Ok, I will check the firewall states and report back tomorrow (alreqdy midnight from where I am). I did not disable logging default blockd and did not add any block rule without logging so I should see the logs you're expecting.
But just to be clear though, the sysctl workarounds that I'm referring are the correct workarounds for what I'm trying to solve, yes?
-
There is no 'correct' workaround here. This might work for you, it appears to have worked for others. It might break at upgrade etc, it's not something we test as NAT on VTI is expected to fail.
By moving the filtering from enc to if_ipsec it should mean traffic is passed outbound on ipsecX and replies are also passed there. No states on enc0.
Using OpenVPN here is the only thing expected to work.
Steve
-
@stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:
There is no 'correct' workaround here. This might work for you, it appears to have worked for others. It might break at upgrade etc, it's not something we test as NAT on VTI is expected to fail.
By moving the filtering from enc to if_ipsec it should mean traffic is passed outbound on ipsecX and replies are also passed there. No states on enc0.
Using OpenVPN here is the only thing expected to work.
Steve
Since Wireguard is now available in pfsense 2.5, will it solve my issue with NAT over VPN?
-
Yes, if you can use WireGuard you can happily route, NAT or whatever across it.
-
If you only have VTI IPsec (no tunnel mode P2 entries) you can also try the patch on https://redmine.pfsense.org/issues/11395 and switch the new option over to filter only on VTI interfaces. Then you can use NAT and rules on assigned VTI interfaces.
