Why no RFC 1918 or Bogon filtering on OpenVPN client interface?
-
blocking what traffic at the openvpn interface.. Who is your vpn provider? Most of those vpn providers use a shared public IP that their clients use and are natted too. It would not be cost effective to give every client their own public IP, which would then allow all traffic to that public IP to go down the tunnel, etc Which is what it sounds like your describing.
Many of the vpn providers that allow for traffic hitting the vpn public IP and go down the tunnel require a port forward/request at the vpn provider to do so.
As to traffic blocking on your wan - yeah the internet is full of noise that is for sure ;) You are naming all the common ports that the bots and such search for. My most common ones are ssh and telnet to be sure..
even if traffic is sent down your vpn tunnel where would it go? You don't have any port forwards setup do you? What rules are in your vpn interface tab? You don't need any rules to use it for outbound access the outbound nat you create sends the traffic down the interface. But all inbound unsolicited would be blocked with the default deny rule, why would you need a specific block rule for rfc1918 or bogon.. When you create a new interface everything is blocked. Pfsense could use that for outbound connections and allow the answers in via states, and you would route traffic out that tunnel via the rules the traffic enters pfsense from your lan.
Only if you were wanting to allow traffic in from that vpn would you have to create rules and a port forward, etc. If that was the case then sure I would put in a rule to block access to pfsense IP in that tunnel network unless you were specifically wanting to allow it.. Did you put some sort of allow rules on your vpn interface you created to route traffic out your vpn? If not I would just assume your logging the default rule and yeah there is noise - its odd that you would be seeing traffic on your vpn interface. But without the details of who your vpn provider is its hard to tell what it might be. But unless you created some specific all rules all traffic would be blocked from the vpn side. Pfsense uses the interface via the outbound nat you created, so your devices can go out the tunnel, etc. But nothing would be allowed in via that interface..
I have a vpn client connection to one of my vps machines, I use it to route some traffic that way every now and then - but I have no rules on that interface. If I try and ping pfsense IP
IPv4 Address 172.27.232.16
Subnet mask IPv4 255.255.248.0In my case from the vps directly nothing.. Unless I create a rule that allows the traffic. Post up your vpn interface rules and we can discuss for sure. But unless you want traffic to come in via your vpn public IP you really don't need any rules there at all.
If you don't want to see the noise you could create a rule there to block and not log. Or just turn off the default rule logging and just log what you want to remove some of the noise. For example there is so much udp noise on the internet I don't give 2 shits about logging that, so I just turn off default logging and created a wan block rule that blocks and logs only tcp syn traffic. Just to see what the bots are looking for ;)
To be honest while blocking bogon and rfc1918 is common practice, in the real world its not buying you much.. Do you actually see hits from bogon?? Keep in mind inbound to your wan is Blocked unless you created a port forward and rule. Blocking rfc1918 and bogon, which do not route on the public internet would only prevent them from hitting some forward or allow rule you created. Any rfc1918 or bogon you would see would normally be just junk noise that you shouldn't even see and it could only be coming from your isp network anyway. If your opening up some port to the public internet at large anyway - what does it matter that some stray packet from a rfc1918 or bogon on your isp hits that port forward??
-
If you assign the OpenVPN client as an interface under Interfaces > (assign), then you'll have the option to add the block private networks/block bogon networks. You'll also have to remove the rules from the OpenVPN tab and put them on the new interface tab.
I agree with johnpoz though, it's highly unlikely you'd want to activate those on a VPN, even for a VPN provider. You should be denying access to all inbound traffic on a WAN-type interface anyhow, and that would naturally block anything that would also be blocked by the private/bogon checkboxes.
From the sound of it, the traffic is already being blocked/logged so I'm not quite sure why you'd need extra options beyond what you already have. Unless you're accepting traffic over the VPN (port forwards, etc) it's all being dropped anyhow.
-
Just to put a picture to what jimp stated - see attached. How is it you have a vpn client connection but not assigned it to an interface? This is kind requirement if you want to nat to this interface and policy route traffic out this interface, etc..
-
Thank you for the replies. Yes, the VPN connection is assigned to an interface. The RFC 1918 and Bogon options are unchecked. I followed instructions similar to https://forum.pfsense.org/index.php?topic=76015.0.
Nothing is allowed in firewall rules for the VPN interface. I could post a screenshot, but it would look identical to John's, only with a lot fewer interface tabs ;D
I was incorrect above when stating that blocks at the VPN interface were occurring at half the frequency as the WAN interface. The number of events has increased >10X since bringing up the VPN client, and are almost all udp. You can see this in the attached graph. I may have to adjust my rule logging as suggested to remove the noise…
Thanks again!
 -
It is odd that you would be seeing traffic on your vpn interface if you ask me. Normally these vpn services do not give customers their own IP its normally shared. And in that sort of setup you wouldn't send traffic down the tunnel unless specific ports were requested and forwarded.
Who is your vpn service provider?
-
Provider is HMA; although, I am researching an alternative. VPN interface is a 10.200.. address. VPN Public is a 167.160.. address
I agree, the public IP likely is NAT'd. Don't know what is causing the chatter. Again, nothing is being allowed through the VPN interface. In fact, I am now explicitly dropping inbound UDP without logging.
See attached pie chart - Blocked inbound traffic on the VPN over 15 minutes - all public IPs.
BTW, what is the default logging rule, and how is it turned off?
Thank you again.
 -
Many people make mistakes when following tutorials and walkthroughs for OpenVPN that suggest creating a pass any any any rule on OpenVPN when setting up a CLIENT connection to a PUBLIC VPN provider.
These connections should be treated like a WAN interface and should, generally, have NO rules on the OpenVPN tab or assigned interface unless you KNOW you want INBOUND connections from anywhere in the world through that VPN connection.
Yes, most of the providers NAT. That is still no reason to have pass rules inbound into your firewall from untrusted sources.
I shudder to think how many PIA connections have pass any any any rules on the OpenVPN tab or assigned interface.
-
That is a valid point Derelict about the guides and creating of any any rules on outbound vpn connections.. I can tell you its prob quite a few setups that are like that..
As to where you turn off default logging, status, system log, settings. See attached - uncheck what you don't want logged.
-
Thank you again for the advice. Fortunately, none of the tutorials I found suggested creating any pass rules. I would have ignored them if they had.
Overall, my pfSense config is fairly simple - no port forwarding rules - UPnP and NAT-PMP are disabled. I did turn off default logging as suggested and added an explicit block rule for TCP with logging enabled on both WAN and OPENVPN interfaces. This has greatly reduced the noise. My VPN connection is over UDP, so that may explain all the UDP blocks on that interface, which were not seen on the WAN interface.
I have another question… What is the OpenVPN interface? It was created automatically when I added the OpenVPN client. It is a tab in firewall rules, but does not appear under Interfaces > (assign).
-
no your openvpn being udp is just the tunnel, what your seeing is blocks inside the tunnel.
