Changing Default Boot Device + Multi LAN with DMZ setup
-
There are a whole load of ways you could conceivably setup the bridge and have it work. The scheme I outlined in the post I linked to above is what makes the most sense logically and conceptually to me. The behavior of bridge interfaces changed between 1.2.3 and 2.X so that threw additional confusion into the mix. Since in 2.X the bridge interface itself is assignable I prefer to have that assigned to LAN. Hence the default dhcp server etc operate on the bridge interface itself and all the bridge member interfaces are configured identically.
Here's the order I would do things in, whilst connected via OPT3.Change the sysctls to move bridge filtering. Do this first because when you create the bridge it will inherit the properties at that point. If you didn't then just reboot, the bridge is setup at boot time with the new settings.
Create the bridge and add OPT1 and OPT2 to it.
Now add the new interface. It will appear as OPT4 with bridge0 assigned to it.
Now change assignments of LAN to bridge0 and OPT4 to re0.
Now add OPT4 to the bridge.Steve
-
I setup OPT 4 as TPLINK24 and changed the LAN to LANBRIDGE. Then, I added OPT 4 / TPLINK24 to the bridge interface, rebooted, and all three interfaces are on now through a wired connection. Thank you.
Now, as it is set I can ping as follows:
pfsense console: WAN / pfsense
OPT 1 / Bedroom: WAN / pfsense
OPT 2 / Netgear16: WAN / pfsense
OPT 3 / DMZ = not setup
OPT 4 / TPLINK24: WAN / pfsenseNotes on OPT4 / TPLINK24:
Pinging .1.2 which is the 24 port switch = Destination host unreachable
Pinging .0.1 which is a wireless router on the switch = request timeout
Pinging .1.118 which is a computer on the same switch = request timeoutIn short regardless of the interface and connection I am only able to ping the WAN and pfsense. All interfaces have rules that pass all IPV4 and IPV6 traffic. Outbound NAT is set to automatic, but it had not created any rules.
-
Ok, I'm slightly confused. I'm not quite sure where you were pinging from. :-\
If the three interfaces (Bedroom, Netgear16 and TPLINK24) are now all bridged they should all be in the same subnet with devices attaches to any of them receiving an IP from the pfSense DHCP server. Any device on any of them should be able to ping any other device attached to them.
If that isn't the case then check the firewall logs. With the sysctls in place to move filtering from the bridge memebers to the bridge interface there shouldn't be any firewalling between the bridge member interfaces and hence nothing in the logs.Your TP-LINK switch may have settings in place since it's a managed switch (yes?). They could be doing something.
The wireless router at 192.168.0.1 is attached directly to the TP-LINK switch? Why is it not in the same subnet? If it is still routing (rather than just acting as an AP) then you will not be able to ping it's LAN IP. If that's the case you should reconfigure it as an AP only unless you have a good reason not to.
https://doc.pfsense.org/index.php/Use_an_existing_wireless_router_with_pfSenseSteve
-
Ok, I'm slightly confused. I'm not quite sure where you were pinging from. :-\
If the three interfaces (Bedroom, Netgear16 and TPLINK24) are now all bridged they should all be in the same subnet with devices attaches to any of them receiving an IP from the pfSense DHCP server. Any device on any of them should be able to ping any other device attached to them.
If that isn't the case then check the firewall logs. With the sysctls in place to move filtering from the bridge memebers to the bridge interface there shouldn't be any firewalling between the bridge member interfaces and hence nothing in the logs.If I am on any interface I can only ping the local IP, pfsense, and the WAN. All of them react the same. When I look at the firewall logs it only shows the last 50 entries, but… Those entries start at Jan 20 22:32:28 and end at Jan 20 22:31:13 . It looks like hieroglyphics to me, but if a screenshot of the log would help I'll take one.
Your TP-LINK switch may have settings in place since it's a managed switch (yes?). They could be doing something.
Yes, it is a managed switch. I have a feeling that the default subnet on the switch is different and may be causing issues.
The wireless router at 192.168.0.1 is attached directly to the TP-LINK switch? Why is it not in the same subnet? If it is still routing (rather than just acting as an AP) then you will not be able to ping it's LAN IP. If that's the case you should reconfigure it as an AP only unless you have a good reason not to.
https://doc.pfsense.org/index.php/Use_an_existing_wireless_router_with_pfSenseSteve
I didn't do this purposely, but it may end up working out better. The plan with the second router was to use it for my parent's house as they live directly across the street from me. I figured if I could setup the second router as a network separate from the rest of my traffic I could setup an access point at their house to amplify the signal. They only use wireless devices so they could cancel their internet service and save some money every month. They've done enough for me so I try to help out in little ways when I can. I was going to setup that interface as a DMZ, but I may just add the interface to the bridge, and have the router set a separate subnet. It probably wouldn't hurt to filter their traffic as well. I will use that to setup the wireless router that I have setup for me though. Thanks.
-
Yes please post screen shots of your firewall rules and firewall logs.
If you can't access machines on other interfaces, even other bridged interfaces, then it sounds a lot like the sysctls haven't worked correctly. Once the filtering has been moved to the bridge interface the switches should appear exactly as though they were physically daisy chained.Steve
-
I realized that I reset the TPLINK switch in an attempt to see if that was the issue. The default IP for the is the same as pfsense so I can't currently log in to check it without moving some lines around.
Firewall rules:
Logs:
-
Hmm, interesting.
So all of that blocked traffic is IPv6. It is DHCPv6 and Link-local Multicast Name Resolution.
There are several interesting things about that. If the filtering has been moved from the bridge memebers then why is anything being blocked on TPLINK24, which is a bridge memeber? Why is that traffic being blocked at all, it's legitimate traffic?
The answer to the second part of that is probably that you have 'block bogons' set on all your internal interfaces. The special destination IPs used for those protocols are probably in the reserved list. You should uncheck 'block bogons' except on WAN. That leads to another question. Usually they wouldn't be checked by default, did you check that yourself?None of that should block traffic between clients though. I take it either you weren't attempting to connect between switches or the logs filled too fast to see it.
Steve
-
Hmm, interesting.
So all of that blocked traffic is IPv6. It is DHCPv6 and Link-local Multicast Name Resolution.
There are several interesting things about that. If the filtering has been moved from the bridge memebers then why is anything being blocked on TPLINK24, which is a bridge member? Why is that traffic being blocked at all, it's legitimate traffic?
The answer to the second part of that is probably that you have 'block bogons' set on all your internal interfaces. The special destination IPs used for those protocols are probably in the reserved list. You should uncheck 'block bogons' except on WAN. That leads to another question. Usually they wouldn't be checked by default, did you check that yourself?None of that should block traffic between clients though. I take it either you weren't attempting to connect between switches or the logs filled too fast to see it.
Steve
The bridge contains; OPT1 / BEDROOM, OPT2 / NETGEAR16, and OPT4 / TPLINK24 . Most of the traffic comes through OPT4 / TPLINK24 that has 17 Windows computers connected. I originally checked block bogon networks on all of the interfaces. I just removed it, but I am still unable to ping outside of the current interface.
I noticed originally looking at the logs that it was all IPV6 traffic that was getting blocked, but the DUID (thanks for the links) were what looked confusing to me. The logs fill up almost instantly although I have watched them while trying to ping an outside interface and it looks exactly the same. If you'd like a screenshot of that as well I can take one if it would help.
In testing all possibilities I thought it might be something with the switch (This is the exact one I own: http://www.newegg.com/Product/Product.aspx?Item=N82E16833704152 ) , but looking into it has the same default IP and subnet as pfsense / what I used so there shouldn't be any issues there. Could it be something with spanning tree settings? I clicked, " Enable spanning tree options for this bridge" when I had the ethernet cables crossed through multiple interfaces and pfsense trying to troubleshoot issues. Perhaps it isn't playing nicely with the bridge?
-
@Beaflag:
I originally checked block bogon networks on all of the interfaces. I just removed it, but I am still unable to ping outside of the current interface.
Is your firewall log still filling with dhcpv6 traffic?
Spanning tree shouldn't cause problems but it shouldn't be necessary either so I'd disable it.
Steve
-
@Beaflag:
I originally checked block bogon networks on all of the interfaces. I just removed it, but I am still unable to ping outside of the current interface.
Is your firewall log still filling with dhcpv6 traffic?
Spanning tree shouldn't cause problems but it shouldn't be necessary either so I'd disable it.
Steve
No, the firewall logs aren't filling up anymore. The only traffic that appears to be getting blocked is from the WAN. Here is a new screenshot of the firewall logs.
I've also disabled spanning tree on the bridge.
-
Ok, that's good. So still not able to ping (or otherwise contact) devices attached to another switch that is part of the bridge? And nothing appearing the logs when you do attempt to?
Hmmm. ???
Steve
-
Ok, that's good. So still not able to ping (or otherwise contact) devices attached to another switch that is part of the bridge? And nothing appearing the logs when you do attempt to?
Hmmm. ???
Steve
That's exactly what has happened. I just tried to ping from one interface to another, I get, "Request timed out," and nothing shows up in the firewall logs. The only interface that is having traffic blocked now is the WAN which has had a few more items have pop into the firewall log since I took that last screenshot.
-
Hmm, hard to say why that isn't working. ???
Lets do a test to make sure that firewall rules are being applied in the correct place.
Add a firewall rule on the LANBRIDGE interface that blocks IGMP (ping) traffic with destination 8.8.8.8. Then verify that you can't ping 8.8.8.8 from any client on any of the bridge member interfaces. Check that the blocked traffic appears in the firewall log.It's just possible that the TP-Link switch is causing an issue here. Have you tried pinging between devices on the BEDROOM and NETGEAR16 interfaces?
After that I think it will be time to run some packet captures to see where the traffic is going.
Steve
-
Hmm, hard to say why that isn't working. ???
Lets do a test to make sure that firewall rules are being applied in the correct place.
Add a firewall rule on the LANBRIDGE interface that blocks IGMP (ping) traffic with destination 8.8.8.8. Then verify that you can't ping 8.8.8.8 from any client on any of the bridge member interfaces. Check that the blocked traffic appears in the firewall log.It's just possible that the TP-Link switch is causing an issue here. Have you tried pinging between devices on the BEDROOM and NETGEAR16 interfaces?
After that I think it will be time to run some packet captures to see where the traffic is going.
Steve
Agreed, I'm confused as to why it isn't working either. I just set a firewall rule on LANBRIDGE that blocks IPV4 traffic / IGMP from any interface to any interface and set it as the highest priority.
Note: Power just went out and it actually saved my post while I was typing it. PFSense actually restarted properly as well after changing the boot device. Thanks.
With the rule in place I am still able to ping pfsense .1.1 from my desktop .1.119 on the BEDROOM interface. It doesn't seem to be blocking anything, but I may have it setup wrong:
I think that somehow the items that are supposed to be bridged are ending up on / with separate DHCP ranges (not sure on exact term). Despite any issues that may be originating from the TPLINK switch / interface as you mentioned I should be able to ping from the BEDROOM interface to the NETGEAR16 . With my laptop plugged in to the NETGEAR16 interface it sets the IP differently. On my laptop ifconfig returns:
inetaddress: .1.28
Bcast: .1.255
Mask: 255.255.255.0In pfsense the DHCP server range is the default LAN of .1.10 to .1.245 . How my laptop ended up outside of that range is a mystery to me? Both of those interfaces are basic unmanaged switches, neither should be able to change what pfsense is sending them. After the power went out I dug deeper into things as everything was down, and it takes a few minutes for everything to restart. I went through all 16 machines on my TPLINK switch and found that all of the IPs lay within .1.1xx with a subnet of 255.255.255.0 . I wanted to get into the switch so I moved some things around. After getting really annoyed with it not connecting I finally pulled the manual to check that the default IP is .1.1 as it says online. Guess what?… it isn't, it's .0.1 with a default subnet of 255.255.255.0 . As of now, the subnet reports 255.255.255.0, on every machines regardless of interface, yet none of them can ping each other.
After getting everything reconnected and running I tried pinging from my desktop to multiple interfaces. It reacted exactly the same as it did before where regardless of the interface I was only able to ping pfsense and the local IP. At the same time I was watching the firewall logs and noticed that it started having IPV4 / LANBRIDGE traffic again. The weird thing I noticed was this:
After looking through every machine I didn't remember seeing a .1.118 so I went through them again to make sure. I don't currently have a .1.118 so this is rather confusing as well as the fact that it keeps sending traffic to google servers. The only thing I can think is that it was my phone or my brother's tablet as he came over to use the internet. The thing is the wireless router has its own DCHP server as I wanted to keep my family off of my network.
Noticing odd traffic I started watching the logs. I'm getting a lot of blocked WAN traffic with a couple IPs coming from China, one from Russia, a server I'm trying to connect to, and a couple other random items. At this point combining network issues with the fact my power keeps randomly shutting off I'm a little frustrated and getting tired of dealing with it. Any help you could provide would be greatly appreciated.
-
.1.28 is within the range .1.10-.1.245 I see no problem there.
I typo'd that firewall rule sorry. Ping is ICMP (not igmp). :-[
So you appear to have several devices on your network that are not being handled by the pfSense DHCP server. Your TP-Link switch is presumably on a static IP at 192.168.0.1? Good job it wasn't at .1.1 because that would have intercepted traffic intended for the LANBRIDGE interface. You say you also have a wireless router handing out IPs? The one connected to the DMZ? That is potentially bad. What range is it using? You can use an additional DHCP instance on the pfSense DMZ interface handing out IPs in a completely different range and then have everything logged and controllable from pfSense. Is the wifi router still routing/NATing?
Those firewall logs are interesting. Why was it blocking traffic from a LAN side client to an external address? You don't seem to have any rules that might do that. Do you have any floating rules? Are you running Snort?
Check the dhcp leases table to see what .1.118 was.
Just to confirm your sysctl tunables look like the attached picture? Though since you have allow all rules on every interface it shouldn't matter.
Steve
 -
.1.28 is within the range .1.10-.1.245 I see no problem there.
Again, new at this. I derped and thought .28 was the equivalent of .280.
I typo'd that firewall rule sorry. Ping is ICMP (not igmp). :-[[/quote]
I changed the firewall rule and it does indeed block my ability to ping anything. The blocked pings are not showing up in the firewall logs.
So you appear to have several devices on your network that are not being handled by the pfSense DHCP server. Your TP-Link switch is presumably on a static IP at 192.168.0.1? Good job it wasn't at .1.1 because that would have intercepted traffic intended for the LANBRIDGE interface. You say you also have a wireless router handing out IPs? The one connected to the DMZ? That is potentially bad. What range is it using? You can use an additional DHCP instance on the pfSense DMZ interface handing out IPs in a completely different range and then have everything logged and controllable from pfSense. Is the wifi router still routing/NATing?
TP-Link switch = .0.1 not .1.1 .
The wireless router is plugged into the TP-Link 24 port switch on the LANBRIDGE. It is box stock so it should be NATing traffic and doing everything else it should be doing. It was only setup temporarily so I wouldn't have my parents or brother coming over and knocking on my door all the time asking me while the internet isn't working while I'm trying to do something. The IP on the router is .0.1 so the same as the switch. Is it possible that is causing an issue?
I'm going to be creating another OPT interface and adding it to the LANBRIDGE eventually. I need some help fishing CAT5e cables, but despite the fact it is for other people they refuse to help get it done. Originally, when I was trying to set everything up I tried to set each interface as their own DHCP server and firewall rules to pass traffic between interfaces. I kept getting DHCP out of range issues or other problems. Again, that is probably me being new at this, but I finally just reinstalled pfsense, bridged it all, and it worked fine aside from the same ping issue I'm having now.
Those firewall logs are interesting. Why was it blocking traffic from a LAN side client to an external address? You don't seem to have any rules that might do that. Do you have any floating rules? Are you running Snort?
No floating rules or Snort.
Check the dhcp leases table to see what .1.118 was.
It was coming from the wireless router. It means it was either; my phone, brother's tablet, dad's laptop, or mom's phone. I'm leaning towards my phone as I just saw it in the firewall logs again and to my knowledge none of those other devices have connected today.
Just to confirm your sysctl tunables look like the attached picture? Though since you have allow all rules on every interface it shouldn't matter.
Steve
Yes, it is set exactly like that:
http://i.imgur.com/ymVFRIm.png -
Hmm, well this is odd. The bridge should just pass all traffic between all it's members . I'll have to run some tests on a bridge here.
So the .1.118 address is that the address of the wifi router if it's still doing NAT? Not that it should matter to the bridge issue. If you have two devices connected to different bridge member interfaces they should both receive an IP address from pfSense via DHCP in the 192.168.1.X range. You should see those two devices in the dhcp leases table. They should be able to ping each other without issue.
Any chance that one of them has a personal firewall running?
Steve
-
Ok, so I have bridge setup here exactly as yours is and I have no problems pinging devices across it.
Some things to check:
Both devices appear in the DHCP leases table. They are both receiving an IP from the same DHCP instance, on bridge0.
Both devices appear in the ARP table.
I have ni firewall rules at all on the bridge member interfaces. It shouldn't be necessary, or even make any difference even, since filtering has been disabled on the bridge members.
When pinging external addresses of the pfSense address the traffic appears in the state table. When pinging other devices on the bridge the traffic does not appear in the state table since it''s neither filtered or routed.My bridge is made up of fxp(4) NICs and yours is re(4) NICs. The Realtek NICs have a bad rep, I wonder if perhaps they're not correctly running in promiscuous mode or some hardware offloading is tripping us up?
If you run ifconfig do you see similar results to my bridge:
bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 ether 00:11:22:33:44:55 inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: fxp4 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 9 priority 128 path cost 55 member: fxp3 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 8 priority 128 path cost 55 member: fxp2 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 7 priority 128 path cost 55 fxp2: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 options=42198 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso>ether 00:90:7f:31:4b:f3 inet6 fe80::290:7fff:fe31:4bf3%fxp2 prefixlen 64 scopeid 0x7 nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>) status: active fxp3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 options=42198 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso>ether 00:90:7f:31:4b:f4 inet6 fe80::290:7fff:fe31:4bf4%fxp3 prefixlen 64 scopeid 0x8 nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>) status: active fxp4: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 options=4219b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso>ether 00:90:7f:31:4b:f5 inet6 fe80::290:7fff:fe31:4bf5%fxp4 prefixlen 64 scopeid 0x9 nd6 options=1 <performnud>media: Ethernet autoselect (none) status: no carrier</performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud></vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud></vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></up,broadcast,running,simplex,multicast>Steve
-
In this test I removed the ICMP rule from the LANBRIDGE and attempted to ping from 192.168.1.119 my desktop to 192.168.1.108 a computer on the TP-Link 24 port switch.
Yes, both appear in the DHCP lease table
Yes, both appear in the ARP table
Rules left exactly the same with filtering disabledAttempting to ping 192.168.2.2 an external address, shows in state filter under, "By Destination IP."
Attempting to ping 192.168.1.108 an internal address also appears in the state table under, "By IP Pair."
I have two of these exact NICs: http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096
The last review mentions he was able to setup link aggregation between the two ports under Windows.ifconfig output:
$ ifconfig re0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 68:1c:a2:12:11:dd inet6 fe80::6a1c:a2ff:fe12:11dd%re0 prefixlen 64 scopeid 0x1 nd6 options=1 <performnud>media: Ethernet autoselect (1000baseT <full-duplex>) status: active re1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 68:1c:a2:12:11:de inet6 fe80::6a1c:a2ff:fe12:11de%re1 prefixlen 64 scopeid 0x2 nd6 options=1 <performnud>media: Ethernet autoselect (1000baseT <full-duplex>) status: active re2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 94:de:80:cc:8d:3b inet XX.XXX.XXX.XX netmask 0xfffffc00 broadcast 255.255.255.255 inet6 fe80::96de:80ff:fecc:8d3b%re2 prefixlen 64 scopeid 0x3 nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex,master>) status: active re3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 68:1c:a2:12:11:db inet6 fe80::6a1c:a2ff:fe12:11db%re3 prefixlen 64 scopeid 0x4 nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>) status: active re4: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 68:1c:a2:12:11:dc inet6 fe80::6a1c:a2ff:fe12:11dc%re4 prefixlen 64 scopeid 0x5 nd6 options=1 <performnud>media: Ethernet autoselect (none) status: no carrier plip0: flags=8810 <pointopoint,simplex,multicast>metric 0 mtu 1500 enc0: flags=0<> metric 0 mtu 1536 pflog0: flags=100 <promisc>metric 0 mtu 33144 lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384 options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x9 nd6 options=3 <performnud,accept_rtadv>pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 syncok: 1 bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 ether 02:f2:fb:65:02:00 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::1:1%bridge0 prefixlen 64 scopeid 0xb nd6 options=1 <performnud>id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: re0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 1 priority 128 path cost 55 member: re3 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 4 priority 128 path cost 55 member: re1 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 2 priority 128 path cost 55</learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></performnud></up,broadcast,running,simplex,multicast></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></promisc></pointopoint,simplex,multicast></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,promisc,simplex,multicast></full-duplex,master></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,promisc,simplex,multicast> -
Ok, here's something I see.
You'll notice the MAC address of the bridge on box is fake where as yours appears to be real. I exepct it to be fake as it doesn't have real hardware to get the MAC from. An issue that has cropped up in the past is that Windows systems can be confused by the fake MAC, especially because it can be generated as a new fake address on each boot. This causes systems >Win XP to label the network as a new untrusted environment and block any connections from them. Not sure if that applies to you.Why can you not ping 192.168.2.2? Does it exist on your network?
Attempting to ping within the same subnet should not appear in the state table, I think we have a clue there. Are your clients receving the correct subnet mask?
Steve
