PF Unwanted LAN to LAN filtering

[byrnejb]

OS: FreeBSD-12.0-RELEASE
Switch: Cisco SLM 2024

We are setting up a new multi-homed gateway host with a PF firewall. We desire that LAN to LAN traffic not be filtered by the PF FW but that LAN to WAN traffic is. Our LAN contains hosts with public and private ipv4 addresses, hosts with public addresses only, and hosts private addresses only. We use NAT for internal workstations requiring external resources. I am unable to come up with a working set of rules that permit unrestricted LAN to LAN communication and still filter on the internal i/f.

The example case is a host with a public ipv4 connecting vis ssh to a host having a private ipv4 address. The ssh session is established and works for a brief time, but then becomes non-responsive. In the pflog we can see traffic from the first host to the second host being blocked by the default

block in all

rule.

   00:00:00.061438 rule 241/0(match): pass in on em0:
216.185.71.44.17457 > 192.168.216.31.22: Flags [S], seq 3972256681,
win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 670920488
ecr 0], length 0

   00:00:00.000028 rule 241/0(match): pass out on em0:
216.185.71.44.17457 > 192.168.216.31.22: Flags [S], seq 3972256681,
win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 670920488
ecr 0], length 0
.  .  .
   00:00:00.023502 rule 499/0(match): block in on em0:
216.185.71.44.17457 > 192.168.216.31.22: Flags [P.], seq 108:144,
ack 1, win 1030, options [nop,nop,TS val 670996382 ecr 2400903835],
length 36

   00:00:00.099675 rule 499/0(match): block in on em0:
216.185.71.44.17457 > 192.168.216.31.22: Flags [P.], seq 0:144, ack 1,
win 1030, options [nop,nop,TS val 671001431 ecr 2400903835],
length 144

The abbreviated rule set in use is:

. . .
### set default action to block everything
block return   out log   all
block drop     in  log   all
. . .
pass              log     quick on  $int_if \
                  from    { self $int_if:network } \
                  to      { self $int_if:network } 
. . .

I do not understand why the second rule does not override the first. Why is this happening? What rule(s) will allow LAN to LAN traffic to be unfiltered?

 

[SirDice]

Traffic between two hosts on the same network doesn't enter at all because they're directly connected. You can only filter traffic if it comes in on one interface and leaves out another.

Our LAN contains hosts with public and private ipv4 addresses, hosts with public addresses only, and hosts private addresses only.

That's just bad design. You should clean this up first. Internal (LAN) hosts should only have internal LAN IP addresses. This is just an accident waiting to happen.

 

[byrnejb]

Traffic between two hosts on the same network doesn't enter at all because they're directly connected. You can only filter traffic if it comes in on one interface and leaves out another.

That is the behaviour that I expect. Unfortunately, it is not the behaviour I observe. Traffic from the LAN to the LAN is most definitely being filtered as evidenced by the pflog entries reproduced above.

 

[SirDice]

It's within the same network (broadcast domain), which isn't the same as on the same LAN. You have multiple networks on your LAN.

For example, 192.168.10.1/24 and 192.168.11.1/24 can be on the same physical LAN but are on two separate networks and are not directly connected. Even if you attach one end of the cable to one machine and the other end of the cable to another they are still not "directly connected". Which is why you need to clean up the internal LAN first. Remove any and all public IP addresses from internal machines. Implement a proper IP numbering plan and stick to it.

Why do some hosts on your LAN require a public IP address at all?

 

[SirDice]

The ssh session is established and works for a brief time, but then becomes non-responsive.

I'm guessing the session is actually idle? If it's idle there's no traffic, which means the firewall state times out after a while. You typically solve this by enabling a "keep-alive" on the SSH session. This will periodically send "null" packets back and forth which keeps the firewall state active.

 

[byrnejb]

It's within the same network (broadcast domain), which isn't the same as on the same LAN. You have multiple networks on your LAN.
. . .
Why do some hosts on your LAN require a public IP address at all?

First, thank you for your help. I appreciate it very much.

We have an established infrastructure that dates to 1995. Originally we used non-private Ps for everything, including the printers, because our initially assigned ip address space was sufficiently large to do so. We also used separate hosts for various network functions. Over time this changed.

The multiple internal private networks evolved as our hosts gave way to virtual machines. Our phone system became internet based and a private network was given to it. The Micro-soft domain DHCP was provided with its own private network block. However, we retain many hosts that we have chosen to retain their assigned public addresses.

My knowledge of networking is limited to my personal experience, which to date has all been on Red-Hat/CentOS systems using IPTables. In this environment we did not encounter the problems we are experiencing with PF although the network configuration at the firewall is identical. Which is why we have the arrangement we do.

The PF firewall is to replace our existing IPTable firewall. This choice was made because we are transitioning all of our *nix systems to FreeBSD. The firewall host is now on deck for conversion from CentOS to FreeBSD. Since manually re-configuring the myriad devices that have been given their IP addresses over the decades is not going to happen we need another solution than rebuilding our entire network from scratch. We can go back to IPTables on CentOS, which we will if this problem iproves insoluble at the router.

Is it possible to 'bridge' the various internal subnets into one on the internal interface? Would that solve the problem?

 

[byrnejb]

I'm guessing the session is actually idle? If it's idle there's no traffic, which means the firewall state times out after a while. You typically solve this by enabling a "keep-alive" on the SSH session. This will periodically send "null" packets back and forth which keeps the firewall state active.

Timeout keep-alive is already configured on the client (ServerAliveInterval 150, ServerAliveCountMax 3) and the server (ClientAliveInterval 150, ClientAliveCountMax 3)
The block happens even while one is typing so I doubt that is problem in any case.

 

[byrnejb]

A bridge will not work. What about a VLAN?

 

[SirDice]

We have an established infrastructure that dates to 1995. Originally we used non-private Ps for everything, including the printers, because our initially assigned ip address space was sufficiently large to do so. We also used separate hosts for various network functions. Over time this changed.

So, after nearly 25 years of organic growth nobody realized it might be time to redesign it from the ground up? If done properly you don't need to worry again for the next 25. I certainly understand how things can grow (been there, done that) but at some point you really have to stop and rethink the situation.

What about a VLAN?

That could work. And is definitely the right way to start. Put each network on its own VLAN. Tie all the VLANs together on the FreeBSD router. You can do all the routing and firewalling there. Best of all, a vlan(4) is a "proper" interface, so it's easy to control traffic to/from it with PF.

 

[byrnejb]

I will try the VLANs first.

The person that does the networking 'thinking' is me and I have many, many more urgent tasks than rebuilding a running network from the ground up, however beneficial that might be. Not to mention the disruption to daily business operations such a task would cause. I am aware of 'technical debt'. But one must first have the money (time) to retire it.

Thank you for all your help. I learned a lot today.