Firewall blocks outgoing OpenVPN traffic to not local network (solved)

Jürgen Garbe

Hello,

pfSense is configured using the following Interfaces:
WAN: 192.168.100.219 (in /24 net)
LAN: 192.168.22.219 (in /24 net)
I created an OpenVPN instance (server) which serves on the WAN interface.
As long as the clients are coming out of the WAN net (192.168.100.0/24) everything is working as expected.

The problem arises, if a client coming from the 192.168.0.0/24 net tries to connect (gateway, routes, … are set correctly):
In this case, the OpenVPN server sees the incoming packets, but the firwall drops all outgoing packets in direction of the 192.168.0.0/24 net.
The only solution I found is to deactivate the firewall (not really a solution) or creating a floating rule with the following parameters:
Pass, quick, direction:any, IPV4, UDP, Source: network 192.168.0.0/24, Destination: firewall(self) on the OpenVPN port.

I even tried to build two separate rules (one for in, one for out) with the same parameters but did not succeed…

Any ideas?

Best regards
Jürgen

johnpoz

Huh?? In what scenario would you have 192.168.0/24 client?? Do you have downstream router connect to your 192.168.22 network? So 192.168.22 is just a transit network?

Your running openvpn server on your wan that is also rfc1918 - so pfsense is downstream of some other network, why would you be running vpn connections inside your own network?

Jürgen Garbe

The pfSense instance with OpenVPN is our remote assistance 'meeting point' where support personal and customers are connecting.
The firewall of this pfSense instance regulates, who is allowed to 'talk' to whom.
Customers, but even support people are connecting from outside using some NAT on an draytec router over our 'Extranet' network 192.168.100.0/24.
This is working flawless.

Sometimes we are giving support with people from inside our organisation, so we are connecting out of our organisations 'Intranet' LAN (which is 192.168.0.0/24) to the 192.168.100.219 pfSense WAN port using our standard gateway (another pfSense instance). This does not work without the mentioned extra rule…

johnpoz

So you these are roadwarrior connections from a specific client, or this is a site to 2 site connection?

What is your tunnel network being used for your openvpn connection?

A drawing would be very helpful! So your pfsense is inside a nat somewhere. So this pfsense wan is just a transit to your edge router, or are there devices on this pfsense 192.168.100 network?

So you are wanting multiple clients on a road warrior connection to talk to each other? Or you have your support people coming in via this connection to go out a site to site connection to support people else where in your network?

Keep in mind if you want to initiate a connection to a road warrior connection you would use the tunnel IP it gets, and its host firewall would have to allow the connection. Also if your remote connection has an overlapping network you could have problems connecting and you would need a source nat.

Again - drawing is worth 10,000 words!!!

Jürgen Garbe

Thank you for your commitment! :)

Please find appended a simple drawing which might explain the situation:
There are customer machines outside in the internet which might need remote assistance.
In this case the customer starts a remote assistance session (he opens a OpenVPN tunnel to our OpenVPN server Firewall-2 - the pfSense instance).
On the other side, some engineer from inside our organisation (Intranet LAN) or even outside in the internet also opens a OpenVPN connection to 'Firewall-2'.
Because the engineers are knowing the address of the clients machines in the OpenVPN net (e.g. 10.6.1.1) they can start their VNC viewer, enter the machines address (-> 10.6.1.1) and can assist the customer.
'Firewall-2' controls, who is allowed to 'talk' with whom.
BUT: as mentioned before, this does not work without this addidtional floating rule…

PS: I forgot to mention: the 192.168.22.0/24 network is only to access the pfSenses WebGUI (and therefor not in the drawing)!

![RA1 pfSense.jpg](/public/imported_attachments/1/RA1 pfSense.jpg)
![RA1 pfSense.jpg_thumb](/public/imported_attachments/1/RA1 pfSense.jpg_thumb)

johnpoz

So your using a /16 for your tunnel network? How many clients do you expect to host?

That looks like a asymmetrical mess waiting to happen. So does the openvpn server have a route 192.168.0/24 Or guessing its bouncing off its gateway? The edge router 192.168.100.2

Out of the box pfsense blocks rfc1918 so if your local is trying to connect to vpn at 192.168.100.219 from 192.168.0 it would be blocked by the default firewall rules the openvpn box. All of these routers/firewalls are running pfsense?

Jürgen Garbe

Because of the fact, that we use static client addresses (client specific configuration of OpenVPN) and having more then 256 Clients we decide to use this 10.6.0.0/16 network…
And of course we added Firewall-1 as gateway to the Intranet (192.168.0.0/24) and the corresponding route in Firewall-2 (which are noth pfSense instances.

What I not understand:
If pfSense blocks rfc1918 (aka private networks?) out of the box, why does it not block the pakets coming from the Edgerouter (source = 192.168.100.2). This is a private network too?

kpa

The "out of the box" blocking of rfc1918 addresses only applies to incoming connections (initiated from the outside) on the WAN interface. On any other interface you have to check the option yourself.

Jürgen Garbe

I see.
But for incoming traffic, the OpenVPN wizard automatically added a rule (source: *, destination: WAN - OpenVPN port).
And incoming traffic was not the problem (I could see the incoming packets in the OpenVPN log both from 192.168.0.0 and 192.168.100.0).
BUT: the outgoing packets in direction to 192.168.0.0 are filtered in 'out of box configuration' by the firewall component, the packets to 192.168.100 not!
That is, what I do not understand…

johnpoz

No the outbound connections would not be blocked.. Post up your wan rules on your vpn pfsense. Also you turned off natting on the firewall-1?

I am talking about routes on your vpn box… His gateway is what? You added a route so he knows to talk to firewall-1 to get to 192.168.0

Jürgen Garbe

I have appended screenshots of the Extranet (=WAN interface) rules, the gateways and the one static route so that the outgoing packets can be routed back to the 192.168.0.0 net.
I am allways talking about Firewall-2 (the VPN box).
Please believe me, I checked the traffic on the WAN interface using the integrated packet capture functionality:
If I disable the firewall functionality, I see the outgoing packets, if I enable it, they are gone (filtered) - the incoming packets an be seen in any case.
Only if I add the floating rule shown in the last screen shot, everything is working as expected - I can see the outgoing packets again!

Extranet.png_thumb

Gateways.png_thumb

Route.png_thumb

Disable.png_thumb

Floating.png_thumb

johnpoz

Why would you set your wan rules to "this firewall" when it would be the wan or extranet address as you have renamed it address as the dest for allowing access to vpn.

What rule(s) do you have in your openvpn interface?

Jürgen Garbe

I set my wan rules to "this firewall" instead of extranet address just as a try. But it really makes no difference.
Please find appended the rules of the openvpn interface (RA1 tecs is an Alias for the addresses 10.6.0.1 … 10.6.0.254).

OpenVPNrules.png_thumb

Jürgen Garbe

Any further hints or questions?
Is it possible to get some logs with info, which (maybe internal/intrinsic) rule filters the outgoing packets?

Jürgen Garbe

Some news:

I am very sad that I am not able to find any hint in the logs of the firewall…
But I played a little bit around and found out that setting the option "Disable reply-to" also solves the problem (although I do not complety understand this option - any hints are welcome)! :o

johnpoz

"any hints are welcome"

Yeah Fix your asymmetrical mess and you wouldn't have to disable reply-to..

https://doc.pfsense.org/index.php/Asymmetric_Routing_and_Firewall_Rules

Jürgen Garbe

Believe me: I really appreciate any hint but can't see in my case, where the hell I use asymmetric routing:
The client A packets (out of the net 192.168.0.0) are routed through GW B (Firewall-1: 192.168.0.200, 192.168.100.200) to the pfSense instance C (Firewall-2 with the OpenVPN service running: 192.168.100.219).
And I think the corresponding "answer" packets are going the same way back (C->B->A), because there is a static route defined in Firewall-2 (C) to direct packets for 192.168.0.0 to GW B!
Where is my mistake, or in other words: where is the asymetric routing?
Best regards!

johnpoz

lets see the traceroutes..

Jürgen Garbe

That helped!
The tracert executed on Firewall-2 clearly showed, that packets in direction of 192.168.0.0 are send to the standard-GW, completly ignoring the defined static route for this case…
It seems, that the firewall on the correspondig interface ("Extranet", 192.168.100.219) ignores the static route and only sends packets to its upstream gateway.
Is there any reason/explanations for dummies like me, why the WAN interface is only working with its one and only upstream gateway and is ignoring the static route?
Best regards!

Jürgen Garbe

Finally got it solved!
At first many thanks to johnpoz to ask the right questions! :)

After learning, what is a transit network (here: my 192.168.100.0/24), how to use tracert, and what is asymmetric routing I finally realized the core misadjustment in my setup: I saw before (and asked, why could it be…) that my static routes just were ignored.
That brought me the solution: I just had to remove the gateway entry in the Extranet-IF settings (now: none) and everything worked as expected!

Now I have learned, that setting a gateway in the interface settings makes the pfSense instance ignoring other gateways and their routes on this interface...