Duplicate states tracked in firewalling bridge implementation

reqman · Mar 9, 2021, 9:42 AM

In a large WAN that has 10/8 addresses, a 10.0.0.0/22 block has been allocated for my local organization premises. I've got a number of systems, some pure LAN clients as well as some "DMZ" system of sorts. In this /22 block I've configured our DMZ systems to take addresses from the first /24 sub-block, whereas LAN devices/clients take addresses from the other 3 /24 blocks available.

On ESXi I've implemented a pfsense 2.5.0 CE VM with 3 vNICs, each one corresponding to LAN, WAN, DMZ and a fourth OPT2 interface that bridges them all. No ip configuration exists on the first three interfaces, management is through an IP address assigned to OPT2.

The bridge works perfectly, even though I can not filter on incoming interface (as I would do if this was a filtering router), but rather on incoming ip: DMZ rules are those for which the ip source is in my designated DMZ address-space, LAN rules are the ones having source ip from the LAN-address space and WAN is mostly everything else. Don't know if this a way to "attack" this problem, I'm open to suggestions if this can be done in a better network-transparent manner :)

One strange thing of this setup is that for two of the interfaces, DMZ and WAN I've attached the related vNICs on VLAN-aware ESXi vSwitches. Had to do that to pass DMZ and WAN traffic on my actual switches to the points of my network they should physically reach (ie floor to floor).

Like I said everything works flawlessly, with one exception: I'm seeing double entries in the states of the rules. For example:

OPT1 	tcp 	89.X.Y.Z:58920 -> 10.0.0.29:443 	ESTABLISHED:ESTABLISHED 	9.727 K / 9.503 K 	434 KiB / 401 KiB 	
OPT1 	tcp 	89.X.Y.Z:58920 -> 10.0.0.29:443 	ESTABLISHED:ESTABLISHED 	9.727 K / 9.503 K 	434 KiB / 401 KiB 	
OPT1 	tcp 	89.X.Y.Z:58187 -> 10.0.0.29:443 	ESTABLISHED:ESTABLISHED 	393.907 K / 331.602 K 	20.11 MiB / 149.31 MiB 	
OPT1 	tcp 	89.X.Y.Z:58187 -> 10.0.0.29:443 	ESTABLISHED:ESTABLISHED 	393.907 K / 331.602 K 	20.11 MiB / 149.31 MiB 	
OPT1 	tcp 	10.210.116.47:4491 -> 10.0.0.29:443 	ESTABLISHED:ESTABLISHED 	239.134 K / 263.176 K 	144.67 MiB / 14.68 MiB 	
OPT1 	tcp 	10.210.116.47:4491 -> 10.0.0.29:443 	ESTABLISHED:ESTABLISHED 	239.134 K / 263.176 K 	144.67 MiB / 14.68 MiB 	
OPT1 	tcp 	10.0.0.97:1097 -> 91.Q.V.W:8883 	ESTABLISHED:ESTABLISHED 	150 / 89 	9 KiB / 9 KiB 	
OPT1 	tcp 	10.0.0.97:1097 -> 91.Q.V.W:8883 	ESTABLISHED:ESTABLISHED 	150 / 89 	9 KiB / 9 KiB 	
OPT1 	tcp 	10.0.0.14:4253 -> 91.Q.V.W:8883 	ESTABLISHED:ESTABLISHED 	1.383 K / 695 	76 KiB / 51 KiB 	
OPT1 	tcp 	10.0.0.14:4253 -> 91.Q.V.W:8883 	ESTABLISHED:ESTABLISHED 	1.383 K / 695 	76 KiB / 51 KiB

Is this "normal" behaviour for a bridge? If not, is there something I should look for?

There are about 100 systems and the states in work hours rise to about 3500-4000 (not a big deal if I understand things correctly).

Not a TCP/IP expert here, this is my first bridge implementation so there are a lot of things I do not clearly understand, so please bear with me :)

reqman · Mar 31, 2021, 10:27 AM

(bump) Someone?