After upgrade from 1.2.3 to 2.0.1 bridging is broken

[ssbaksa]

Hi.

As subject says I have problem with bridging. After update, something what worked for more than 3 years was broken. In attached schema you can see general idea.

Interfaces em1 and em2 are bridged. em1 has IP address x.y.202.9 with some aliases. em2 is just bridged + firewall. On both segments I have servers. Inside networks are on VLAN's and IP aliases on WAN are used to NAT each VLAN to different IP.

Before upgrade servers x.y.202.3 and one behind firewall x.y.202.120 were accessible by inside clients/servers. Now I can't even ping servers on inside bridged segment (x.y.202.120) dough x.y.202.3 is still there. I can't ping even IP's on em1 interface.

I have even added allow all to all interfaces as first rule but it didn't do any good.

What can I do. Where to look for clues. Going back to 1.2.3 is not an (welcomed) option.

BTW - This rule is something that looks strange to me:

pass out route-to (em1 161.53.202.1) inet from 161.53.202.9 to !161.53.202.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"

Br

Sasa


[ssbaksa]

To replay to myself.

Now, in 2.0.1 if you wish bridging to function as before, you must:

1. assign bridge to interface
2. than assign that bridge to interface
3. enable new interface
4. Create pass/bloc/drop rules according to you "taste"
5. Now you have bridge that is up & running.

Found&Done by using few old firewalls still running old pfS versions and my favorite pfctl -sr.

[ssbaksa]

Another update.

It works from one bridged interface to another one.
It is still broken from NAT'ed one to inside bridge interface.

[wallabybob]

There are some sysctls that control whether packet filtering is done on bridge interfaces or their members - see System -> Advanced click on System Tunables tab. Perhaps you are falling foul of those settings.

[ssbaksa]

@wallabybob:

There are some sysctls that control whether packet filtering is done on bridge interfaces or their members - see System -> Advanced click on System Tunables tab. Perhaps you are falling foul of those settings.

I have also thought so but after changing this parameter there was no difference.
Anyway I will try it again. Tnx for sugestion.

Sasa

[ssbaksa]

No change!

From 172.16.84.254 icmp_seq=193 Destination Host Unreachable
From 172.16.84.254 icmp_seq=194 Destination Host Unreachable

From inside VLAN:

root@njuskalo:~# ping 161.53.202.90
PING 161.53.202.90 (161.53.202.90) 56(84) bytes of data.
64 bytes from 161.53.202.90: icmp_seq=1 ttl=64 time=0.376 ms
64 bytes from 161.53.202.90: icmp_seq=2 ttl=64 time=0.331 ms
64 bytes from 161.53.202.90: icmp_seq=3 ttl=64 time=0.299 ms
64 bytes from 161.53.202.90: icmp_seq=4 ttl=64 time=0.442 ms

From bridged network interface:

root@master:~# ping 161.53.202.90
PING 161.53.202.90 (161.53.202.90) 56(84) bytes of data.
From 172.16.84.254 icmp_seq=6 Destination Host Unreachable
From 172.16.84.254 icmp_seq=7 Destination Host Unreachable
From 172.16.84.254 icmp_seq=8 Destination Host Unreachable
From 172.16.84.254 icmp_seq=9 Destination Host Unreachable
From 172.16.84.254 icmp_seq=10 Destination Host Unreachable
From 172.16.84.254 icmp_seq=11 Destination Host Unreachable

[stephenw10]

After changing the sysctls you will have to reload the firewall rules (or reboot). Possibly also the state table?  :-\

You should see something in the firewall logs to indicate where/if it is being blocked.

Steve

[ssbaksa]

@stephenw10:

After changing the sysctls you will have to reload the firewall rules (or reboot). Possibly also the state table?  :-
You should see something in the firewall logs to indicate where/if it is being blocked.
Steve

Rebooted (not only once) Weird thing is that there is no log for that traffic. Isn't state table cleared with reboot?
I have used this option to:

Disable reply-to Disable reply-to on WAN rules
With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.

but no positive result. This is hell. I am using pfSense (M0n0Wall before that) for years and this is problem which makes me frustrated. I am missing something obvious but…

root@master:~# ping 161.53.202.90
PING 161.53.202.90 (161.53.202.90) 56(84) bytes of data.
From 172.16.84.254 icmp_seq=6 Destination Host Unreachable
From 172.16.84.254 icmp_seq=7 Destination Host Unreachable
From 172.16.84.254 icmp_seq=8 Destination Host Unreachable
^C
--- 161.53.202.90 ping statistics ---
8 packets transmitted, 0 received, +3 errors, 100% packet loss, time 7008ms

root@master:~# traceroute 161.53.202.90
traceroute to 161.53.202.90 (161.53.202.90), 30 hops max, 60 byte packets
1  zidic.efos.loc (172.16.84.254)  0.127 ms  0.118 ms  0.109 ms
2  zidic.efos.loc (172.16.84.254)  0.142 ms !H  0.134 ms !H  0.170 ms !H

[ssbaksa]

Well, just to inform those interested.

After a struggle decision was laid and I have moved my FW to version 1.2.3 and all was back as it was.
No problems with bridging and NAT.

Sasa Baksa