Can't connect from site A to site C
-
If you're trying to reach C from A via B, then you need to port forward through both B & C, but it's hard to tell from your sketch which way NAT is going. For example, you say you can reach B, but it shows the path to B is through C.
-
Yes it might be a bit tricky indeed. On the drawing I signed the VPN between site A and B. But of course this runs via site C and the internet. In site A there is NAT from 192.168.1.x to the internet. In site B there is NAT from 192.168.2.x to 192.168.3.254. And in site C there is NAT from 192.168.3.x to internet.
Thanks to the VPN, all hosts in sites A and B can reach each other.
Hosts in site B can access a server in site C. And hosts in site A should be able to do this too. Hosts in site A should be given the gateway from site B as default gateway (192.168.3.254)
Hope it is like that a little more clear. Is a bit difficult to explain.
-
You shouldn't need to port forward anything here if you only need to reach C from A.
You just need to make sure the IPSec tunnel has P2s for both A-B and A-C.
Steve
-
I don't know exactly how you want to do this. Because what do I enter at local subnet when I add a P2 to the IPSec tunnel. Should this be 192.168.3.0? And does pfsense understand that this must be routed to site C or do I have to do something for that as well?
-
Unless you are using route based IPSec (VTI) then IPSec is policy based. You have to have P2 policies to match all the traffic you need to carry which here includes: 192.168.1.0/24 to 192.168.3.0/24.
pfSense will send that to the site at C as long as it has a route to it. I imagine it's the default route though it's not clear from the diagram.
Steve
-
I spent all day testing different things. But still don't have it working. I have now a P2 policies that match all the traffic (192.168.1.0/24 to 192.168.3.0/24) And the default gateway on site B (pfSense ) is to site C. But I still can’t reach it.
I think the outbound NAT on site B (pfsense) is incorrect. I have already added a extra rule for 192.168.1.0 but unfortunately also without result.
And the stupid thing is when I replace the pfsense with the old draytek it works in one go :-(
So it must be a settings in the pfsense router. Only I can't find it yet.
-
Do you see the traffic blocked in the firewall logs anywhere?
Do you see the correct states open in pfSense in the state table?
Does the host at site C see the requests?
Steve
-
Sorry, yes on the firewall I have the following message:
Dec 29 08:55:57 WAN Default deny rule IPv4 (1000000103) 192.168.3.246:80 192.168.1.252:36028 TCP:SAstate table:
IPsec tcp 192.168.1.252:36106 -> 192.168.3.246:80 SYN_SENT:ESTABLISHED 4 / 762 240 B / 36 KiB WAN tcp 192.168.1.252:36106 -> 192.168.3.246:80 ESTABLISHED:SYN_SENT 4 / 762 240 B / 36 KiB -
When I remove the NAT rules for 192.168.1.0 then the entry on the firewall log disappears.
-
Oh yes and I see the request coming from site A on the server in site C
-
The fact you are seeing SYN-ACK replies blocked on WAN usually means some sort of route asymmetry but it could also be the state timed out and that was a reply to the last SYN.
The state there does not show the traffic being NAT'd as it leaves the WAN. I expect to see that source NAT's to 192.168.2.X, whatever the WAN IP is.
It's possible that was an old state though.
Without NAT there the host at 192.168.3.X will need a static route back.
What are your outbound NAT rules there?
Steve
-
On site C is a static route for 192.168.1.0/24 to 192.168.3.254 (this is the WAN for site B). On site C is only NAT to the public IP.
On Site B I use the following NAT at this moment.
-
If you have a static route at site C you should not need an outbound NAT rule at B but you will need firewall rules at C to pass it. The default LANnet pass rule will not.
Steve
-
Got it working finally. For this I reset everything to default and started again from scratch. And both options now works. If I do it via NAT it works. And if I change this to a static route in the destination network (so without NAT) it also works.
I think I have the same configured as before. But apparently something was wrong before, because now it works.
Thank you all for your input and suggestions.
