Changing Default Boot Device + Multi LAN with DMZ setup

Beaflag VonRathburg

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:

stephenw10

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

Beaflag VonRathburg

@stephenw10:

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?

stephenw10

@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 VonRathburg

@stephenw10:

@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.

stephenw10

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

Beaflag VonRathburg

@stephenw10:

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.

stephenw10

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

Beaflag VonRathburg

@stephenw10:

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.0

In 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.

stephenw10

.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

![bridge tunables.jpg](/public/imported_attachments/1/bridge tunables.jpg)
![bridge tunables.jpg_thumb](/public/imported_attachments/1/bridge tunables.jpg_thumb)

Beaflag VonRathburg

@stephenw10:

.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.

@stephenw10:

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.

@stephenw10:

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.

@stephenw10:

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.

@stephenw10:

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.

@stephenw10:

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

stephenw10

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

stephenw10

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

Beaflag VonRathburg

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 disabled

Attempting 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>

stephenw10

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

Beaflag VonRathburg

All clients on the TP-Link 24 port switch are Windows computers. There's thirteen Windows 7 and three Windows 8.1 . My laptop does have Kubuntu 13.10 on it and has the same issue though so I'm not sure.

192.168.2.2 does not exist on my network so I used it as such to test that it would appear in the state table when I attempted to ping it. I haven't done anything of this before so I'm trying to be as thorough as possible.

Despite all the clients being bridged and on the same subnet I am still unable to ping anything, but pfsense. Regardless of the interface, device, or OS. When, I went through all of the computers attempting to determine what device .1.118 was I checked to make sure all computers and my TP-Link switch are on the 255.255.255.0 subnet. Using ifconfig and ipconfig confirmed that and all devices do report the subnet mask as being 255.255.255.0 .

stephenw10

Presumably you can ping other devices that are connected to the same switch?

I thought of one other thing I have that is non-standard on that box. I have IP fast forwarding enabled. That shouldn't make any difference at all but I'm running out of ideas. ::) It's a sysctl on the system tunables table. By default it's off because it breaks IPSec. Try setting it to 1.

You could try disabling the hardware offload options in System: Advanced: Networking: I can't really see how that would help either. :-\

Anyone else got any suggestions for a bridge that isn't forwarding packets? Or more accurately clients that seem to be sending all traffic to their gateway even that for their own subnet?

Time to run some packet captures and see what's up.

Steve

Beaflag VonRathburg

Power issues have been raping my life right now, but… While dealing with all of that crap I might have found something.

IP fast forwarding didn't do anything differently.

Windows 8.1 ipconfig shows different results than that of Windows 7. All of my Windows 7 computers show the subnet mask as 255.255.255.0 and my 8.1 machines do as well, but only for the section that says ethernet adapter to ethernet. Where it says something along the lines of local connection 1, 2, 3, 4, etc... it shows the subnet mask as 255.255.0.0 . I'm guessing that despite the bridge being setup and all the subnets of local hardware being set to 255.255.255.0 it is getting switched some where along the way.

stephenw10

A bad subnet mask is exactly the sort of this that might cause this. If your client machines don't realise they're in the same subnet as others on the bridge (or supposed to be as least) then they will send traffic via their gateway instead of directly. However for that to happen they would have to have a smaller subnet mask like 255.255.255.224 not a much larger one as you've discovered.

If that was the case then you might have a problem pinging other clients even on the same switch.

I don't have a Windows 8 machine to look at here so I'm not entirely sure what you're referring to. Do you have a screenshot or the output from ipconfig?

I assume you can't ping ping between two Win 7 clients on different switches though?

Steve

Beaflag VonRathburg

I can't ping anything even if they're sitting right next to each other on the same switch. This has been tested with on all of my switches with three different operating systems. Here is what I was speaking of in regards to Windows 8.1 showing odd subnet behavior.

When the bridge originally broke I had to keep using ipconfig release and renew to actually get it to connect automatically. That was due to me changing how the switches were connected around, but it might be a clue?