site2site only working in one direction!?!
-
Hi,
I have been banging my head against the wall for the last couple of days and a dent is beginning to show - but not in the wall.
I have managed to set up WG site2site between to pfSenses. One is to call the other via its FQDN. Handshake is working fine.
And from site B I can access the network on site A while from site A I cannot access the network on site B (there are identical firewall rules "any to any" on both sides of the WG tunnel and on both sides the allowed IPs for the tunnel and the peer are 0.0.0.0/0 and I have set up corresponding routes on both sites).
The only thing that is different - and I can't figure out why is that if I ping a server on site A from site B, I can see in the FW logs on site A that the source of the ping is the PC that I am pinging from on site B. But if I ping a server on site B from site A, I see in the FW logs on site B that the ping is coming from the pfSense A (instead of the PC that I am pinging from on site A). So my theory is that the traffic goes through fine from site A to site B but the response from site B is directed at the wrong recipient (FW A instead of PC A).
So my question is: Why would pfSense A replace the IP of PC A with its own when sending the traffic through the tunnel? There is probably a setting hidden somewhere... (I set up pfSense A a long time ago whereas I set up pfSense B just recently. So I may well have changed various standard settings of pfSense A over time but not on pfSense B.)
Or, maybe my theory is wrong? If you have another ideas what might be going on, I appreciate any comments.
Thanks for your help!
-
It looks to me like you have a misconfigured Outbound NAT rule that is preventing the translation of the IP address to the original machine. Compare them on both machines and see you can see the difference between them.
-
Thanks @dma_pf !
I thought this could explain it:
So I had actually set up the WG tunnel before on pfSense A to allow a mobile to connect to base and have its internet traffic routed through pfSense A's WAN (by creating a NAT mapping for traffic from the tunnel network to go through the WAN interface). And I thought that this could explain the problem I'm facing now (particularly given that the IP address pfSense A replaces PC A's IP with is pfSense A's WAN address)...
But - surprisingly - disabling this NAT mapping in pfSense A does not change the result: the pings logged in pfSense B still seem to be coming from pfSense A rather than from PC A.
After disabling the mapping, to me the remaining NAT settings of pfSense A and pfSense B look quite similar (with one difference: pfSense A has "Hybrid Outbound NAT rule generation enabled" and pfSense B "Automatic outbound NAT rule generation". But the resulting automatic rules look essentially the same.)
What else could make pfSense replace the client's IP with its own?
-
@sensewolf Not exactly sure what's going on but it seems like a misconfiguration somewhere. Here's a video from the developer of the Wireguard package that goes through a step-by-step setup of a site-to-site WG configuration. Try using that as a guide to double check you didn't miss something on your configuration. https://www.youtube.com/watch?v=2oe7rTMFmqc. Let me know what you find out.
-
Thanks @dma_pf !
I had seen this video a while ago but while setting up the WG tunnel, I had followed other tutorials.
It did prompt me to make minor changes to my configuration (I had created gateways on the tunnel network with the local rather than the remote IP of the tunnel and now I changed it to the respective remote IP for both sites - but that changed nothing: Site B to Site A was working before and is working now while Site A to Site B wasn't working before and isn't working now).
Otherwise, I would say, my setup is identical to the one demonstrated in the video (well, I have different IP addresses for my LANs and for my tunnel network but that should not matter; and the WG Handshake works and Site B to Site A also works).
There was a remark about unwanted NATing that happens when you choose an upstream gateway for the WG tunnel interface - which I didn't do (and this lead to yet another IP replacing the client's IP, not the WAN IP - so this does not seem to be closely related to my problem).
I have also tried and reset the States (which he does in the video after manipulating the NATing). But this, too, has had no effect: The traffic from Site A arrives at pfSense B and is shown as coming from pfSense A's WAN address rather than from the actual PC A.
But I am more convinced than ever that this is a NAT problem: I played around with the NAT settings on pfSense A and was able to alter the source IP shown on pfSense B (to yet another IP) but unfortunately not to the real source IP. I also tried a mapping that was to keep pfSense A from NATing this particular traffic but that did not change anything).
So what else could make pfSense A alter the source IP when it sends traffic through the WG tunnel???
Oh, just to rule out another potential issue: pfSense is the same version (2.5.2) on both Sites.
Banging my head against the wall harder than ever (feeling the problem has been identified but kepps escaping a solution)...
-
@sensewolf Any chance you can post some screen shots of your NAT rules?
-
Sure, @dma_pf :
So, there is only one manual mapping for my 3CX PBX system. But that should have no impact, right?
The rest is the automatically created rules.
In the meantime I played around a bit more and set up an OpenVPN site to site tunnel, to rule out that it is a Wireguard problem: The OpenVPN tunnel behaves exactly the same. I can reach Site A from Site B but not vice versa. The firewall logs on Site B show that the traffic is coming from pfSense A's WAN address.
(In the screenshot above you can see the OpenVPN tunnel (highlighted), not the Wireguard tunnel. The screenshot is from Site A. Site B does not even have the one manual mapping but is only the automatically created rules).
So, more than ever, I believe it has to do with the NATing but I can't figure out what the problem is.
Thank you again for taking the time to look into it!
-
I have a (small?) update:
Earlier I said that in the FW logs of Site B the origin IP address (of Site A) is wrong (which lead me to assume that it is a NAT issue).
However, I was wrong: The origin IP address is correct (it is not pfSense A's WAN address).
Given that the origin IP is correct, I am now tending towards thinking it may be a misconfiguration on pfSense B (rather than pfSense A).
But for the life of me, I can't figure it out.
The traffic goes through from Site A to Site B alright (I am logging the Allow rule so I can see that it goes through). And I can see on server B that the ping from Site A is coming in. And since I can ping from inside the same network, I know that the server responds to pings.
So it seems that for some reason the reply is swallowed on the way back to Site A.
But why??????
-
@sensewolf Have you tried doing a packet capture on the server from pfsense (Diagnostics/Packet Capture)? Ping the server while the capture is running. What does the capture show? Is the ping getting to the server? Is the server responding to the ping? If so what IP address is it sending its response to?
Do you see any states created between your client and the server?