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

[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)!


[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!

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

[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:

1. I am very sad that I am not able to find any hint in the logs of the firewall…
2. 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...