pfSense and IPSEC lan to lan: a big doubt about the correct implementation
-
Do you have a new diagram showing those subnets?
So 3.3.3.3/25 is not a public subnet?
If both sides are behind NAT you will need to forward the IPSec traffic through one of the external routers to pfSense in order to bring up the tunnel reliably. Without that you rely on both ends opening outbound states at the same time that match the incoming traffic which may or may not happen.
Steve
-
-
Ok, so is 10.55.0.0/24 at site B a public routed subnet there?
If not both sides are behind NAT and you will need to forward traffic in router A and/or B to establish the connection.
-
In your original diagram you have a /30 transport subnet bewteen the ISP and Router B and then a /25 behind Router B which looks like it would be a public subnet?
-
@stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
Ok, so is 10.55.0.0/24 at site B a public routed subnet there?
Yes, it is :) in the real scenario it is a public routed subnet.
-
Ok, then you need to replicate that. pfSense B has a public IP and the tunnel should be using that directly, not the router B address.
-
I also note that the pfSense IP is 3.3.3.2 and you appear to have used 3.3.3.3 as the remote host IP at site A. Is that a typo?
-
@stephenw10 yes, it was a typo, but, please, refer only to the last schema I attached here :)
-
@stephenw10 mmmmmc ok, you are right. thank you.
Do you know how can I do it in GNS3 first?
Thanks,
Mauro -
Well you would need to add 10.55.0.0/24 as a static route via Router B. Then in router B configure it not to NAT that traffic.
Or just remove router B entirely and put 192.168.122.205 on pfSense B directly.
-
@stephenw10 many thanks again for your patience.
Now the schema is the following one:
And it seems that something is working (thank you Steve).
At this moment, there is no traffic forward rule on RouterA.
The IPSEC tunnel is started from pfsenseA (I only added the identifier as you suggested)Now the last step before closing this case.
PC1 and PC2 are not able to ping each other. IPSEC firewall rules allow any traffic to any hosts, but there is this last problem.On every pfsense interfaces there is a single rule that allows any traffic to any hosts and ports.
What do you think I'm missing ?
-
Ok so the tunnel is up at P1 and P2. The subnets it's carrying look correct.
The traffic counters show 0 packets in or out. Does it show that at both ends?
I would guess that you are missing the route on Router A to 192.168.120.0/24 via pfSense A.
Client at site B should still be able to send though and that should match the policy and be sent over the tunnel.
-
Unfortunately, the route on router A has been already set.
-
Ok, then check both ends, do the traffic counters still show as 0 after trying to ping in both directions?
How exactly are you running that ping?
Do you see anything blocked in the firewall logs?
-
@stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
Ok, then check both ends, do the traffic counters still show as 0 after trying to ping in both directions?
yes, 0 stats on both the ends
How exactly are you running that ping?
I'm executing ping from the VPCS on the left of the schema (192.168.118.10) to the VPCS on the right (192.168.120.10) and viceversa
Do you see anything blocked in the firewall logs?
During the last attempts, it seems that nothing have been blocked but I will check again soon
-
The other thing to check is the state table in Diag > States. You should see states on the LAN and IPSec interfaces for the pings on each side.
At site B there is really nothing to stop IPSec at least sending pings from 192.168.120.10 to 192.168.118.10 over the tunnel.
At site A there are other things that could be preventing it. -
Ok, these are the states for the pfsenseA
and these are the states for the pfsenseB
Question: on the Router A I created a route 192.168.120.0/24 > 10.99.0.2.
Do I need to create a route rule also on pfsense A ? something like that: 192.168.118.0/24 > 10.99.0.1? -
I see no icmp states at all between the two subnets in either of those tables. Were the pings running?
You should not need to a route back on pfSense A because Router A is the default route there. (Or at least it should be!)
-
@stephenw10 yes, the pings are running and I'm making some tests on both the directions.
I checked again the firewall logs. no rule is blocking the traffic.
I'm trying to understand where is the error -
If there are still no icmp states then either there are firewall rules blocking that traffic or the pings never arrive at pfSense. A pcap on the pfSense B em2 interface should show that.
