New OpenVPN install accessible on lan but not from internet

viragomann

@LPD7
Only in the general settings: "pfBlockerNG enable"

DNSBL doesn't matter here.

LPD7

@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).

SteveITS

@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.

viragomann

@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.

LPD7

@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.

SteveITS

@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.

LPD7

@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?

SteveITS

@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?

LPD7

@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.

LPD7

@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.

SteveITS

@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.

Gertjan

@LPD7

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.

LPD7

@SteveITS That is what I was thinking, something "got stuck" but how do you figure out what it may have been? I would figure with all the logs that one may shed some light but I haven seen anything that jumps out at me. I setup the client on the laptop and over wifi it connects, havent had a chance to try it from the cell hot spot yet.

Gertjan

@LPD7 said in New OpenVPN install accessible on lan but not from internet:

havent had a chance to try it from the cell hot spot yet

Then do so.
Because that's what you want (I guess) : be able to reach your pfSense and/or LAN from 'everywhere'.

As soon as you connect to your WAN IP, you should see this :

I have a VPN connection right now to my pfSense, so there is 1/ connection and /123 Kb of traffic. This counter goes up upon receiving traffic that matches that rule > a proof that OpenVPN traffic comes into the OpenVPN server.

If your counters stay at 0/0 then you know that traffic isn't even reaching pfSense.

I didn't know I could use a device on the pfSense LAN, and use it to connect to the OpenVPN server running at pfsense but, hey, why not. Using the WAN interface ( ?? ) that's more delicate as that would be needing NAT refection (I guess). Never needed to do that.
My situation : when I'm using a device on my LAN, I can use https (TLS), so the connection to the GUi is pretty good protected, no need to wrap that secure traffic in another encrypted tunnel.
When I'm outside, and want to access the GUI, I fire up the OpenVPN on my device, and then I can connect to my pfSense GUI, or any other LAN based device like the airco, NAS, dvr, printer, whatever.

LPD7

@Gertjan Hello Gertjan thanks for replying, I have pasted the floating rules below.

I have removed the RFC1918 rule but wondered if based on my read of the details if either option (see below ) isnt a good thing to have for added security. I am going to read up more on these to get better educated on their intended purpose.

Regarding your comment "Your second (and now only) OpenVPN firewall WAN rule : change "WAN_0 address" for 'This Firewall', what impact will that change have? This also is new to me.

I have tested the VPN access using my cell phone and the providers assigned IP address with wifi off and it is able to connect so am hoping/expecting that when using the hot spot from the laptop the results should be the same but will verify here shortly to confirm.

PS.. The chevron image in your profile, are you/were you Navy?

LPD7

@Gertjan Ok so I was able to connect to the VPN from my laptop using the bluetooth connection for the hot spot since I disabled wifi on the cell phone to ensure all traffic going over cell provider. Cell service is weak here so it is slow but traffic is passing (see below). So I guess given this can now confirm vpn is working across the 2 devices as expected but why the initial issue or can it be considered a one off and is everything else setup as it should for best performance and security.