(IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP
-
Not at all. I only have one peer serup on both sides.
-
Hmm
-
@stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:
Hmm
Can I file it as a bug?
-
Yes, if you have details there and can replicate it.
-
I think I'm seeing the same behavior.
My setup might be a bit different but I have two netgate appliances: SG-3100 & SG-5100 and site2site wireguard vpn setup according to the howto. After disabling the WAN inbound firewall rules for 51820 on both devices and even killing states the link still comes online.Since disabling the rules didn't work I set an explicit reject instead of allow, but connection still comes up... So it seems wireguard doesn't care about my WAN rules.
-
That is expected if both sides have a remote IP and there in nothing NATing in between them. Both ends open an outbound UDP state with 51280 as the source and destination port. The traffic arriving from the other side can use that open state to connect.
This should be a new thread in the WireGuard or Firewall subs at this point. It's no longer IPSec related at all.
Steve
-
@stephenw10
Thanks for the answer, not my intention to hijack the post. It just seemed relevant to the WG related questions. You are correct both sides have remote IP defined, but also explicit firewall WAN -rules to reject the connection.Is this expected, even though I restarted one of the firewalls (e.g no active states)
-
If the reject rules are inbound they won't do anything over the default block rule. The default outbound allow rules will still allow the state to open on each end letting the traffic enter from the remote side.
Steve
-
Thanks again for the clarification, so this basically means that the WAN inbound rules as in howto are not necessary at all in this scenario?
https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-s2s.html
Wish you a great day.
-
There is no harm in adding them to the specific remote IPs and it may allow the tunnel to come up faster. Without then it can only establish once both sides are sending outbound traffic.
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 harm in adding them to the specific remote IPs and it may allow the tunnel to come up faster. Without then it can only establish once both sides are sending outbound traffic.
Steve
Does that mean both sides can be behind a CGNAT device (WAN interface is private IP) and the WG tunnel can still be established because both ends will just open a state when they initiate an outbound connection?
-
Unlikely.
It would work as long as they were both using dyndns to give the other something to open a state to and the provider is not using source port randomisation. They probably are though.Steve
