Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPsec NAT not working #369

Closed
fraenki opened this issue Sep 6, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@fraenki
Copy link
Member

commented Sep 6, 2015

OPNsense 15.7.11-amd64

Following the information given here I've added IPsec configuration to NAT a local network before sending the traffic through the tunnel. But it seems that this IPsec-related NAT configuration is not working on OPNsense.

Setup:

  • IPsec tunnel network: 172.16.1.0/24 (local) <=> 10.1.2.0/24 (remote)
  • NAT network: 192.168.0.0/24 should be translated to 172.16.1.254 for destination 10.1.2.0/24

I can see that a NAT rule is actually added:

# pfctl -s nat | grep 10.1.2.0
nat on enc0 inet from 192.168.0.0/24 to 10.1.2.0/24 -> 172.16.1.254

When doing a ping 10.1.2.1 from a host in 192.168.0.0/24, I can see with tcpdump that the packets arrive at the appropiate firewall interface, but they are not forwarded to 10.1.2.0/24 (at least there is no matching traffic on interface enc0).

The states table shows this:

# pfctl -ss |grep 10.1.2.1
all icmp 10.1.2.1:26770 <- 192.168.0.1:26770       0:0
all icmp XXX_WAN_IP_XXX:65464 (192.168.0.1:26770) -> 10.1.2.1:65464       0:0

The firewall log does not show any denied packages.

@fraenki

This comment has been minimized.

Copy link
Member Author

commented Oct 7, 2015

Just discovered a similar report:
https://forum.opnsense.org/index.php?topic=989.0

AdSchellevis added a commit that referenced this issue Oct 12, 2015

(ipfw) reverse behaviour for non captiveportal pass rules in ipfw, is…
…sue #369

same issue could appear on otheri non physical interfaces as well in the previous version
@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Oct 12, 2015

@fraenki we've tested the feature and could reproduce the issue over here. There we're two issues:

  1. ipfw (traffic shaper, captive portal) was blocking your traffic, a6c6016 fixes this issue
  2. The identification of the leftsubnet was faulty, which caused connection issues after reboot. This should be fixed by c72484e

If you have the time, could you test the fixes on your end as well?
I will close this issue for now, if for some reason it's not completely solved, just let me know and we will reopen it.

@AdSchellevis

This comment has been minimized.

Copy link
Member

commented Oct 12, 2015

Thanks to markt.de for funding this fix!

@fraenki

This comment has been minimized.

Copy link
Member Author

commented Oct 12, 2015

@AdSchellevis Good job! Works as expected now. :-)

AdSchellevis added a commit that referenced this issue Oct 13, 2015

AdSchellevis added a commit that referenced this issue Oct 13, 2015

(ipfw) reverse behaviour for non captiveportal pass rules in ipfw, is…
…sue #369

same issue could appear on otheri non physical interfaces as well in the previous version

(cherry picked from commit a6c6016)

AdSchellevis added a commit that referenced this issue Oct 13, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.