Bypass firewall rule for static routes

fluca1978

Hi,
I'm not sure if this is a firewalling topic or a routing one, I'm quite desperated.
I've got a firewall with two NICs connected to two different LANs, one is called LAN and one LAN2. The LAN is connected to the network 192.168.4.0/24 and the LAN2 interface to the 192.168.44.0/24 network. Both the interfaces must connect to the 192.168.1.0/24 network thru the 192.168.4.245 router and the 192.168.44.245 router.
The first problem is that I cannot define a double static route for such network, I can define a static route to 192.168.1.0/24 via LAN interface but cannot add another route to 192.168.1.0/24 via LAN2 interface, since the system answers that a route to such address already exists.
However, I can connect to the other hosts on the 192.168.1.0 network both from LAN and LAN2, but when LAN2 tries a connection (e.g., SSH) the firewall drops the connection after 20 seconds because of the default drop policy, even if there is a check on the "bypass firewall rules for traffic on the same interface".

The firewall log says:

The rule that triggered this action is:

@76 block drop in log quick all label "Default deny rule"

So my questions are:

how can I specify a static route for the LAN2 network?
how can I allow the LAN2 to connect to another network without having the firewall to drop the connection?

Thanks

fluca1978

Having a look at the rule summary, from the shell, I have the followings:


pass in quick on nfe0 inet from 192.168.4.0/24 to 192.168.1.0/24 no state label "pass traffic between statically routed subnets"
pass in quick on nfe0 inet from 192.168.1.0/24 to 192.168.4.0/24 no state label "pass traffic between statically routed subnets"
pass out quick on nfe0 inet from 192.168.4.0/24 to 192.168.1.0/24 no state label "pass traffic between statically routed subnets"
pass out quick on nfe0 inet from 192.168.1.0/24 to 192.168.4.0/24 no state label "pass traffic between statically routed subnets"

this enables nfe0 (LAN) to pass the traffic, while I should have a similar set of rules for the rl0 network card (i.e., the LAN2). I've tried to statically add a route to a single host on the other net for the LAN2, but it does not work either.
Myabe I have to create a port redirection since the LAN interface is working? If I redirect the LAN2 -> 192.168.1.0 any port to LAN I can get connect? Any idea?

mericksonj

I'm going to make the assumption that the gateways (x.x.[4|44].245) you're using to reach the 192.168.1.0/24 is the same multi-homed router(s) that is also NOT the pfsense firewall? It seems an odd configuration that would look something like this:

LAN1
/
pfsense –>[] []--- 192.168.1.0/24
\ /
LAN2

This is the only assumption that would make some sense out of why you need dual static routes to the same destination via different gateway interfaces that the LAN1/LAN2 hosts or firewall wouldn't already know about. The best answer to this would be to put the static routes on the LAN1/LAN2 hosts, or to use a dynamic routing protocol to make sure everybody knows about it.

If you MUST use your firewall as an unnecessary next-hop (unnecessary at least until you add rules to restrict traffic), you will NOT be able to make both LANs route symetrically as you wish to do. One interface or the other will have to act as the route to the x.x.1.0/24 network using static routes.

What will probably serve your needs best (but is probably not the easiest or best way to do it) is to use policy based routing in your rule. When you configure your rl0 and nfe0 interface IP addresses, if you haven't already put in a gateway IP 192.168.[4|44].245 then you'll need to do that.

Next, when you define your rules for traffic destined for 192.168.1.0 from LAN1/LAN2, the rules will have a "gateway" option on the web GUI page, simply select the appropriate gateway. The traffic inbound from 192.168.1.0/24 won't need the same gateway, it will be managed by the rules similar to what you already have for nfe0.

Hope this helps!
–James

fluca1978

Your assumptions are right, so now I'm using policy routing, but there is something joking on me. The following rule allows the traffic to pass from the network 192.168.44.0 to the 192.168.1.0 via 192.168.44.245:


block drop in log quick on rl0 route-to (rl0 192.168.44.245) inet proto tcp from 192.168.44.0/24 to 192.168.1.0/24 label "USER_RULE: Lan2 -> 192.168.1.0"

but the following rule does not and triggers the default drop in quick rule:


pass in log quick on rl0 route-to (rl0 192.168.44.245) inet proto tcp from 192.168.44.0/24 to 192.168.1.0/24 label "USER_RULE: Lan2 -> 192.168.1.0"

Now, I admit this is quite astonishing, since the rule that is working is, in fact, a drop rule!! And I'm seeing in the logs that the packets should be dropped, while they are passed. What the hell am I missing?

The following is the set of rules tied to the 192.168.44.0 network, maybe this strange behaviour lies in here:


pass in quick on rl0 inet proto udp from any port = bootpc to 192.168.44.7 port = bootps keep state label "allow access to DHCP server"
pass out quick on rl0 inet proto udp from 192.168.44.7 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
block drop in on ! rl0 inet from 192.168.44.0/24 to any
block drop in inet from 192.168.44.7 to any
block drop in log quick on rl0 route-to (rl0 192.168.44.245) inet proto tcp from 192.168.44.0/24 to 192.168.1.0/24 label "USER_RULE: Lan2 -> 192.168.1.0"
pass in log quick on rl0 route-to (rl1 XX.XX.XX.XX) inet from 192.168.44.0/24 to ! 192.168.1.0/24 flags S/SA keep state label "USER_RULE: Lan2->World"

shadowadepts

i might be miss understanding you but could you not just create Static Routes entries point to your lan?
then create pass rules on each interface.

LAN0 = 192.168.1.x
LAN1 = 192.168.4.x
LAN2 = 192.168.44.x

LAN0

| LAN net | * | LAN1 | * | *
| LAN net | * | LAN2 | * | *

LAN1

| LAN1 net | * | LAN0 | * | *
| LAN1 net | * | LAN2 | * | *
LAN2
| LAN2 net | * | LAN0 | * | *
| LAN2 net | * | LAN1 | * | *

fluca1978

How can I manage static routes since the system does not allow the multi-static routing thru different interfaces? It is not clear to me your solution, could you please explain better?

mericksonj

Shadow,
I think what you're missing is that LAN0 is not an interface on the firewall, so it makes things a bit harder.

Fluca,

You've got two separate BSD processes going on here that are going to tell a packet where to go.

The first is the normal routing process as shown in your routing tables, this is not going to do what you want it to do because there is no mechanism for discriminating which next-hop should be selected from the routing table based on anything the L3 packet header other than destination IP. It is a rather "dumb" process which will just choose the shortest prefix from its routing table that matches the packets destination and after matching that, forward the packet out the interface (in your case nfe0 which is controlled by that default block you mentioned in the first post).

The second process here is something akin to (and I'm a newbie here so don't quote me) iptables mangle on Linux. This will match a packet with some logic (your rules) and evaluate the network and the interface the packet arrived from. The logic will then adjust it's next-hop action to match what you want done in your rules (policy).

The limitation here (I think) is that the rules are going to flag interesting vs uninteresting packets and choose the best of these two processes to handle the packet's routing. The "pass" rule makes the packet uninteresting to the policy and the firewall will forward the packet based on its first process without logic other than basic IP forwarding.

The "block" rule makes the packet "interesting" to the policy and the firewall will evaluate it and act upon it according to the policy logic you're defining.

This flagging interesting vs uninteresting may have something to do with the "quick" option in the rule, but as I said I'm new here, my background is in routing not pfsense and I can only guess that the keyword does what i think it does. someone else can correct me if I'm wrong.

Hope this helps!
–James

shadowadepts

@mericksonj:

Shadow,
I think what you're missing is that LAN0 is not an interface on the firewall, so it makes things a bit harder.

oh ok my bad. ya ignore that.

Fluca1978,
outta curiousity why do you need the two 4/44 networks. there might be a better solution. you may need to configure them differently. could you better explain what your attempting. because there is another method.

fluca1978

My idea is to have two separated lans to be routed thru the pfsense machine to internet and other networks. It's a kind of double-department setup where each department must be kept separated but must have the same routing decided by the pfsense machine.
I think the other solution is using vlans, but that too is causing some problems.
Suggestions?

mericksonj

Which direction is your ISP? Through the 192.168.1.0/24 or via WAN on the Firewall?
What other networks are involved locally? or is it just the 3 local networks+WAN(ISP)?

fluca1978

The ISP is connected thru the WAN, while the internal networks are connected only to the 192.168.1.0 (and together).
Is this wrong?

mericksonj

Nothing wrong specifically, if you don't have the NICs available on the PFsense for an interface for the 192.168.1.0/24 network, and aren't too concerned about security.

It would be Ideal to use the firewall to make the routing decisions, let it be the local router instead of the device you're using now.

The router you have between the local subnets now is sort of a weak link in your security scheme; it probably isn't a security device (correct me if I'm wrong). If you want the best security/control over your three networks, try to get another NIC added to your firewall.

Without the PFsense performing true gateway functions for all LAN networks you leave yourself with a hole into 192.168.1.0/24 as well as a back-door into your other networks. It wouldn't be that difficult for a malicious attacker, if he can sniff your IP numbering and deduce network topology to use local access to either of the 3 networks or a trojan horse running SOCAT/NETCAT-like binary to force its way into your other two networks.

If you aren't too concerned about the security, feel free to leave it how it is, the policy with the block (interesting that it's not the pass rule) is apparently doing what you want it to do with the policy-based routing, so you might want to set up both interfaces with a similar rule and leave it at that.

shadowadepts

meric is right. it would be the easiest to just install another card in the pfs box and then pfs box could be your wan end point or just point to another router. by setting up strict firewall rules you can create network isolations or not.

pneumoboy

Maybe coming in a little late, but I have a similar configuration using VLANs without an issue. Basically each subnet is on its own VLAN. For you:

192.168.1.0/24 VLAN1
192.168.4.0/24 VLAN2
192.168.44.0/24 VLAN3

Each subnet's default gateway resides on the pfSense box. And each VLAN has its own Firewall ruleset, which you can use to control the traffic between the VLANs. So it is possible to let both 4/44 talk to 1, but 4 cannot talk to 44 and 44 cannot talk to 4.

My corp configs use one physical interface for the trunked link (for all the vlans), and one physical interface for management (that is not trunked). No one says you cannot use a trunked link for management, but for sanity (and fat finger mistakes) I keep them separate.

medora

@pneumoboy:

Maybe coming in a little late, but I have a similar configuration using VLANs without an issue. Basically each subnet is on its own VLAN. For you:

192.168.1.0/24 VLAN1
192.168.4.0/24 VLAN2
192.168.44.0/24 VLAN3

Each subnet's default gateway resides on the pfSense box. And each VLAN has its own Firewall ruleset, which you can use to control the traffic between the VLANs. So it is possible to let both 4/44 talk to 1, but 4 cannot talk to 44 and 44 cannot talk to 4.

My corp configs use one physical interface for the trunked link (for all the vlans), and one physical interface for management (that is not trunked). No one says you cannot use a trunked link for management, but for sanity (and fat finger mistakes) I keep them separate.

I have this configuration setup, but for me the rules are negated by the "Default deny rule" and any connection to the other VLANs are dropped by the firewall.
Any ideas of what a possible problem is?