Site-To-Site OpenVPN not working - no tunnel traffic
-
Just me being dumb and anal, but can you ping 10.10.100.14 from 10.10.100.1 (pfsense Local LAN gateway) just to prove your PC can respond to a ping?
If 192.168.58.1 can ping 10.10.100.1 and vice versa, then as far as I'm concerned then tunnel is up and the WAN rule is correct (we can leave it alone).
Your OpenVPN rule is exactly what I would expect, allow everything.
You might temporarily add a new LAN rule on both ends set to pass and Log ICMP. Put it at the top of your rules to try and track if the requests are hitting each pfsense box at all.
Don't ya just love theses "opportunities" to learn about the details :o
-
can you ping 10.10.100.14 from 10.10.100.1
Yes, successfully. Just tried it to make sure.192.168.58.1 can ping 10.10.100.1
Yes, just tried from both locations. All is good there.Your OpenVPN rule is exactly what I would expect, allow everything.
That's good news.temporarily add a new LAN rule on both ends set to pass and Log ICMP
Ok, I did that. Here is what is odd:
from 10.10.100.14 and 10.10.100.11 (site-B) I ping'd 192.168.58.2 (site-A) but the firewall log showed this activity on firewall 10.10.100.1 (site-B). I would have expected that traffic to show up at the remote site, site-B (192.168.58.1). See screenshot below. Is that wrong? Do I have OpenVPN traffic looping back to the local LAN?Thx, again!
-
Ok, I did that. Here is what is odd:
from 10.10.100.14 and 10.10.100.11 (site-B) I ping'd 192.168.58.2 (site-A) but the firewall log showed this activity on firewall 10.10.100.1 (site-B). I would have expected that traffic to show up at the remote site, site-B (192.168.58.1). See screenshot below. Is that wrong? Do I have OpenVPN traffic looping back to the local LAN?The log file shows that a rule was activated by some traffic. The traffic originated on the LAN interface and was destined for 192.168.58.2. That is probably exactly what would be expected depending on how you wrote the rule that was triggered. You didn't mention if the ping from 10.10.100.14->192.168.58.2 was successful?
Did you try the inverse test (192.168.58.2->10.10.100.14) and see what the logs show?
If you can post the temp LAN rules from both ends we should be able to see where we're going.
-
You didn't mention if the ping from 10.10.100.14->192.168.58.2 was successful?
That ping failed.
Here is the rule that was triggered:
from 10.10.100.1 LAN (site-B):IPv4 ICMP, *, *, *, *, *, none, , TEMP: TEST PING
The same rule was setup on 192.168.58.1 (site-A firewall, LAN) but was not triggered.Did you try the inverse test (192.168.58.2->10.10.100.14) and see what the logs show?
I didn't try that. 192.168.58.2 is 34 miles away. So far all testing has been from the physical/geographical site of site-B. I have other servers at the site-A location but none of them are behind this firewall.I can ping from inside the site-A firewall from the LAN side (192.168.58.1) to a site-B and I get a ping response! whoa! wha'd'ya know?! But what is odd is that neither "TEMP: TEST PING" rule (from each side) was triggered. Both LAN temp rules are on the top of all other rules (ordered first).
If you can post the temp LAN rules from both ends we should be able to see where we're going.
Site-A LAN Temp Rule: IPv4 ICMP, *, *, *, *, *, none, , TEMP: TEST PING
Site-B LAN Temp Rule: IPv4 ICMP, *, *, *, *, *, none, , TEMP: TEST PING -
Does anyone see any problem with the rules as they have been defined?
-
Upgraded from 2.1.3 to 2.1.4 today hoping something would finally work. Nope.
Can't ping remote LAN devices but can ping remote tunnel endpoint.
-
I'm not making any traction on this issue so I'll start the process of getting pfSense Corporate help - start with a 2 hour chunk of time and see what can be done. I really don't want to because it's $400, so if anyone has any more ideas, I'm listening.
Thanks for the help thus far.
-
resolved via premium support.
-
Care to post the solution?
-
Solution?
Don't have a newb setup the VMware host server. :-[ The problem was that there wasn't a gateway defined on the host server.
It ended up not being an OpenVPN/pfSense issue.