New OpenVPN install accessible on lan but not from internet
-
I had an instance of OpenVPN running fine on my PFS CE box until I had to reinstall a backup which also had the openvpn service configured and working but after the restore when I tried to access my network from the VPN it didnt work so after a couple of hours trying to figure out why I decided to delete everything and start from scratch.
Using the tutorial from Lawrence Systems on YT, I reconfigured OVPN and was still not able to connect, below is what I have done/discovered since. Please keep in mind that this was working with no issues before restoring the backup config and all packages are up to date and the system is green/good to go.
- I use a ddns service to point to my box and it is up and running and can ping it from my ios device which I am using to test as I can test both local and external (cell network) access.
- Looking at the system logs>firewall I could see the ios device trying to connect using the ip assigned by the provider (I used whatsmyip to get the ios devices ip address) BUT ONLY after I pinged the ddns address. Prior to this and for a reason I can not explain the ios device was not showing up in the logs until after I pinged the ddns ip address.
- Not knowing which data connection the ios device was using (cell or wifi) to access the PFS box, I shut down the wifi and tried to connect using only the cell network which did not work but I did see the ios device cellular ip in the source column of the firewall log. However, when I activated the wifi and tried to connect not only did I see the local ip address of the ios device show up in the firewall log but the device successfully connected to the vpn server.
Based on the above I have made the following inferences:
- The client is setup correctly and can access the VPN albeit only from the local network.
- The issue must be (semi educated guess) related to a firewall rule again because I can connect but just not from outside the local network.
I understand FW rules but not enough to blindly start adding rules which may compromise my network.
My goal is to have my network accessible via the VPN regardless of device type or ip address from which I am attempting access, as long as the ssl/tls and user authentication match access should be granted.
Any help in resolving this would be greatly appreciated.
-
@LPD7
If you disable the wifi on the phone to go over the cell and try to connect, what do you see in the clients log?
Is the IP correct?Is you OpenVPN server listening on WAN?
Or did you forward the packets?Do you have a firewall rule on WAN to pass the OpenVPN packets?
-
@viragomann Thanks for your reply. I am a bit confused because I am seeing the cellular ip address in the log but it seems like it is both approved and rejected, approved as part of a list I have installed and rejected as part of what I would assume is a default IP4 rule (see attached). 223.11 is the ios over cell and the 114.11 is the ddns address. The ip's are correct. I have included the FW rules as well so you can see if anything jumps out at you.
FW log entry while trying to connect via cell ip:
Current fw rules:
-
@LPD7 said in New OpenVPN install accessible on lan but not from internet:
and the 114.11 is the ddns address.
Can you recheck that this IP is shown up in Status > Interface at WAN_0?
The pass rule on WAN doesn't show any hit. So I expect, that one of its conditions does not match the traffic.
The pass log entry might be just a "match" from a pfBlockerNG rule.
-
@viragomann Thanks for that insight. I have pasted the wan interface status info and to me seems like its correct, but I am no expert. My look at the wan rule seemed like it was to pass/allow the VPN traffic but this is where my capabilities get limited as I am still and seems ever learning about this system.
-
@LPD7
Yes, looks well.
So it's pretty strange, why the rule doesn't work.Try to disable pfBlockerNG for testing and also reboot pfSense.
-
@viragomann I will give that a try and update you on results. This is curious as it worked before reloading the backup. Stay tuned.
-
@viragomann Real quick, should I also disable IP as well as DNSBL which are also under pfblockerNG within the firewall menu?
-
@LPD7
Only in the general settings: "pfBlockerNG enable"DNSBL doesn't matter here.
-
@viragomann That did it I can now access via the cell network. Now that we know the PFB was the issue how can I resolve it and still have the benefits of PFB running. I noticed the moment I disabled PFB the firewall log exploded with a bunch of red "X's" and green check marks (see sample below).
-
@LPD7 https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/firewall-rules.html#permitting-traffic-to-the-openvpn-server
If there was a rule on WAN blocking the port or source IP, then be aware rules are processed in order. In pfB there are settings for ordering rules it creates, or you can create each rule as Alias Native which only creates an alias, then you create your own rules as desired.
One can disable logging of the default block rules, in the pfSense log settings.
-
@LPD7
So you have pfBlockerNG set to create match-rules?
I only know what it is from theory, never used it. So not clear, what they do in your setup.
Normally you might want to get block rules from pfBlocker. -
@SteveITS Hi Steve how are you? Its been an while hope all is well. This is where my confidence in doing this correctly gets shaky so I will look over the link you sent and see if I can make sense of it. I pasted screen shots from the FW rules and it seems like everything pretty much gets passed on through.
-
@LPD7 I realized after I posted you only had two rules showing there on WAN. Unless they got reset though the 1194 rules has 0/0B so hasn't matched anything. Though, your pfB rule in the log allowing North America also isn't visible...?
See https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html as there are cases where irrelevant/extra packets can be blocked, and that can be ignored.
If you're connecting from the Internet then the LAN rules and OpenVPN rules are not relevant to the process of connecting. The OpenVPN rules are relevant after connecting.
-
@SteveITS Great explanation as always. I ran with your comment about not seeing North America in a log and found within Firewall>pfblockerNG>IP>GeoIP that the North America list is set to Match Both for action. Assuming this was the issue based on your keen eye, I went ahead and disabled it, re enabled pfB and connected to the VPN from the cell network and was able to do so. Does this point to the NA list as the culprit? and if so how do I resolve it while keeping the NA list in tact?
-
@LPD7 said in New OpenVPN install accessible on lan but not from internet:
the North America list is set to Match Both
Hmm, seems unlikely then:
'Match' or 'Log' only the traffic on the stated interfaces. This does not Block or Reject. It just Logs the traffic.Match Both - Matches all traffic in both directions, if the source or destination IP is in the list.
"Back away slowly" and see if it breaks again?
-
@SteveITS Just as an update, to make sure nothing got stuck and this was not a fluke I logged off the VPN rebooted PFS and reconnected to the vpn and it has been connected ever since.
When you say back away slowly should I re enable the NA list and see if it breaks again or do I set the action to something else? This is where I my current lack of knowledge kicks in.
Is there a rule I can create to allow the NA list to operate but ensure all vpn traffic is not hindered?
If I am seeing things correctly the problem lies at the ingress, the WAN interface, right?
What I have realized is that since disabling the NA list I am seeing a heck of a lot or red X's (block) in the firewall log, a lot more than I have ever seen before, out of 500 records not a single green check (allow). Not sure if that is anything or just the result of disabling the list.
-
@SteveITS Ok so this is strange. I reenabled the NA list as it was before and I am able to connect. Now I know that prior to disabling the list I wasnt able to connect and the logs confirmed that. So what could have happened and is it temporary? May not have pinpointed the issue but wondering if this is a lead.
-
@LPD7 I would wild guess when it was disabled and pfBlocker updated/reloaded it added or removed something else that hadn’t been applied yet.
-
WAN :
Remove (de activate) the first 'RFC1918' on your WAN. Not really useful there anyway.
Your second (and now only) OpenVPN firewall WAN rule : change "WAN_0 address" for 'This Firewall'.
During a OpenVPN server test, not from LAN, but using a device connected some where else, like 'the Internet' using a data roaming connection (= shut down the Wifi on your phone), or your neighbors place.Btw : You've shown all the firewall rules on all the interfaces, but not the Floating rules.