Traffic Isnt Jumping on Tunnel
-
I recently set up a Site to Site OpenVPN connection between our main pfSense Firewall and an off-site location (see below).
Site A 10.X.X.X <->pfsense1 LAN (10.X.X.X)<->pfsense1 (VPN: 10.100.124.1-server)<->INTERNET<->pfsense2(VPN:10.100.124.2-client)<->pfsense2 LAN (192.168.X.X)<->Site B 192.168.X.X
Currently Site A can route and access anything on Site B (ping / network resouces / etc) but Site B cannot ping pass the pfsense2 box. The routing tables on both pfsense machines look perfect and the remote networks seem to be set up fine on both as well. Site B's clients have a route saying to go to pfsense2's LAN IP to access the 10.X.X.X network but the traffic stops dead there.
Both pfsense's have any/any rules in the firewall for both normal and OpenVPN firewalls, in fact, NAT'ing and Firewall are completely disabled for pfsense2 (its between another firewall anyways).
Any suggestions? Beat my head against the wall for two days so far on this with no luck.
Thanks!
-
Because you can access B from A, that means that B devices do have effective routes back to A. So the routing should also be OK for states that originate from B going to A.
Sounds like some firewall issue on pfSense1 on the incoming OpenVPN interface is not allowing traffic from Site LAN IPs to SiteA LAN IPs.
And I assume that 10.x.x.x is not 10.0.0.0/8 - otherwise it overlaps the VPN tunnel. Those are all private addresses, so you can put the real numbers you are using - none of us can DOS you at private IPs:)
If it is all as you describe then it should work. There will be some little setting/rule in error/overlooked. For us to help you spot that, you really need to post actual screen shots. -
Thanks for taking the time to respond!
Below are the rules for this VPN Subnet on pfsense1:
Server Config:
Client Config:
The 10.2.X.X/16 subnet could be a bit overlapping with the 10.100.124.0/24 subnet, but this is the only instance (6 other OpenVPN [non-site to site]) that is having issues.
Thanks again!
-
No overlap there - 10.2.0.0/16 is only all addresses starting with "10.2".
The rules for the VPN subnet on pfSense1 are not showing enough of the page - allowing traffic from just 10.100.124.0/24 will not be enough. You need to allow traffic from those 192.168 subnets. But I can see that there is another pass rule coming further down - can't quite read it!
For testing, and since this is all internal traffic anyway, I would be putting a pass all rule at the top of the OpenVPN tab. Then see if connectivity works. After that you can put more restrictive rules and then you know when it breaks that it is the rule-set you just applied. -
Phil, you are my hero!
That was it, I didn't think a rule to allow the 192.168 subnet would be necessary. That did it though! Now I'll have to clean up the rules but we have full connectivity now. I appreciate your help!
Thank you so much sir!
-
Happy to help.
The addresses checked in rules are the real source and destination addresses of the packets arriving on the interface, which often (usually) are not in the interface subnet itself.This only gets "messed up" when there is NAT happening somewhere - if you are receiving packets that have been NATed somewhere by the sender then the source IP (destination when heading back to the NAT) will be whatever the NAT rewrote it to.