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

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