Changing Default Boot Device + Multi LAN with DMZ setup
-
I preemptively apologize if any of this sounds odd to the network gods on here. I currently have two issues. The first is setting the default boot device. Upon booting pfsense everything works fine, but during boot the default boot device is incorrect and from the console it prompts me to enter the correct boot device. Along the lines of:
? List valid disk boot devices <empty line=""> Abort manual input</empty>
Entering ? provides a list of devices and I having determined the correct one I enter:
ufs:/dev/ad4s1a
Which will then continue with the boot process and start pfsense. I've done a lot of searching on here and from the sound of things it sounds like I need to edit the etc/fstab to set the default boot device.
http://forum.pfsense.org/index.php?topic=28751.0
https://forum.pfsense.org/index.php/topic,41201.msg212866.html#msg212866
https://doc.pfsense.org/index.php/Boot_TroubleshootingThe issue is that I am not aware of how to do this and continually turning things off and on is not currently an option. I know this one sounds simple so any help would be greatly appreciated.
–-----------------------
My second question is in regards to setting up a multi or bridged LAN setup throughout my house with a separate DMZ. My current setup as I hope to have it:
modem --> pfsense --> LAN = 24 port managed switch (garage) / includes Dlink WLAN
OPT1 = 8 port unmanaged switch (upstairs)
OPT2 = 16 port unmanaged switch (downstairs)
OPT3 = E3000 second wireless router (upstairs / different room DMZ)The pfsense box is in a central location so having all LAN traffic flow through the 24 port switch / default lan is not an option as it is not physically possible without rewiring the whole house. I hope to have all of the LAN and DLink WLAN traffic to be able to communicate to each other while the second WLAN e3000 is setup as a DMZ for guests.
I previously had the setup run as a LAN bridge by following the information posted here:
http://forum.pfsense.org/index.php/topic,20917.0.html1. On Interfaces Assign page create another OPT interface called OPT2 (create more than one if you want to bridge physical ports too - we'll call any additional ports OPTx.)
2. Assign a physical port or a vlan port, or a PPP port to OPT2 just as a place holder.
2a. Assign physical ports to the other OPTx interfaces you've created.
3. Go to the Interfaces -> OPT2 page and click the "Enable" checkbox. (Repeat for all OPTx interfaces.)
4. Go to the Interfaces -> (assign) page and click on the "Bridge" tab.
5. Select OPT1, OPT2, OPTx (if you created additional ports for the bridge) to be members of the bridge interface and Save.
6. Go to Interfaces -> (assign) page again and select "BRIDGE0" for the LAN interface, and select the fx1 port (formerly assigned to LAN) for the OPT2 interface and Save.The only thing I had to do differently from the above was step 6. Instead I changed the LAN to BRIDGE0 and left the OPT1 interface as the port it was actually connected to otherwise nothing could connect on that interface. This worked fine for me aside from the fact that the devices on separate line were not able to ping each other.
Two days ago I had a power outage that somehow broke my LAN bridge, basically not passing internet through any interface. I power cycled all devices, but was ultimately forced to reset everything to default through the console. I thought I would just reset it the way I had it and I'd be good to go, wrong... I attempted to duplicate my setup as I had it before, but it would not work. As soon as I changed the LAN interface to BRIDGE0 it would lock me out of the web GUI, I would be forced to reset the interfaces in the console, and power cycle the machine. If you combine that with the original issue of the incorrect default boot device this became annoying very quickly.
I ended up only being able to get traffic through the LAN interface and had to use an extra 20 foot CAT5e cable and a 5 port 10/100 switch to make the line from 8 port switch long enough to plug into the 24 port switch to allow upstairs to function. While this does currently function it is an unacceptable long term solution so I'd like to get this figured out.
At this point I've been doing a lot of research and I'm a little unsure of how to attack this. I've read a lot of bridge and DMZ guides, but am still confused. I'm not sure if the bridge is really necessary or if I could set firewall rules to allow the multiple LAN interfaces to communicate, but then combining that with the DMZ makes it more confusing.
TLDR
Problem 1:
Change default boot device from unknown setting to ufs:/dev/ad4s1a so pfsense will boot automatically without prompting.Problem 2:
Setup multi lan interface that can communicate to each other with a separate DMZ. VLANs and passing all traffic through LAN is not an option.
Any help would be greatly appreciated.
-
Hey.
You can edit the fstab any number of ways. From the webgui Diagnostics: Edit file: click browse and navigate to /etc/fstab.
From the console using the easy editor (or vi if you're a masochist!):ee /etc/fstab
In the fstab you will see a list of mounted file systems. You will want to change the root and swap references appropriately. You haven't listed what it was trying to mount before but you know where root is. The swap slice will also be on ad4.
Have read through this post bout creating a bridge:
http://forum.pfsense.org/index.php/topic,48947.msg269592.html#msg269592
It seems like you didn't move the bridge filtering.
So your want what is your current LAN interface bridged with OPT1 and OPT2 but keep OPT3 separate yes? I would reocmmend you add firewall rules, if you haven't alreday, to OPT3 to allow you to access the webgui. Then setup the bridge from the OPT3 network. That way you are far less likely to be locked out as you change the interface configs.Steve
-
Hey.
You can edit the fstab any number of ways. From the webgui Diagnostics: Edit file: click browse and navigate to /etc/fstab.
From the console using the easy editor (or vi if you're a masochist!):ee /etc/fstab
In the fstab you will see a list of mounted file systems. You will want to change the root and swap references appropriately. You haven't listed what it was trying to mount before but you know where root is. The swap slice will also be on ad4.
That did indeed work and it does automatically boot, thank you. Changes:
Old # Device Mountpoint FStype Options Dump Pass# /dev/ad6s1a / ufs rw 1 1 /dev/ad6s1b none swap sw 0 0 New # Device Mountpoint FStype Options Dump Pass# /dev/ad4s1a / ufs rw 1 1 /dev/ad4s1a none swap sw 0 0
Have read through this post bout creating a bridge:
http://forum.pfsense.org/index.php/topic,48947.msg269592.html#msg269592
It seems like you didn't move the bridge filtering.
So your want what is your current LAN interface bridged with OPT1 and OPT2 but keep OPT3 separate yes? I would reocmmend you add firewall rules, if you haven't alreday, to OPT3 to allow you to access the webgui. Then setup the bridge from the OPT3 network. That way you are far less likely to be locked out as you change the interface configs.Steve
Yes, I read that before I before I setup the first bridge and couldn't get it to work. As odd as it sounds the bridge I had setup previously worked fine without bridge filtering, but it cut my download speed in half. As soon as I enabled bridge filtering, speed returned to normal: http://i.imgur.com/PcC9FBn.png
Currently it is set as follows:
System Tunables
Interfaces:
Bridge:
All interfaces are assigned, enabled, and block bogon networks. The LAN interface has the default LAN settings of Static IPV4 and Track Interface with the default IP. All other interfaces are simply enabled without having an IPV4, IPV6, or IP.
All interfaces have firewall rules passing IPV4 and IPV6 traffic as the basic * * * * * none .
As soon as I change the LAN interface to BRIDGE0 it locks me out of the web GUI and cuts out WLAN traffic. LAN traffic stays running, but the OPT interfaces do not work. Adding the LAN to the bridge does not work as it returns:
You cannot set port bridge0 to interface LAN because this interface is a member of bridge0.
If you need any additional screen shots or info let me know.
-
I assume you have renamed LAN as TPLINK24? But is still has the usual default LAN rules?
Where/how are you connected to the pfSense box when you set LAN to bridge0? I strongly advise you to be connected via an interface that isn't (and isn't going to be) part of the bridge when you set this up. I've set up bridging a number of times and I'm familiar with what pfSense will do and I still manage to lock myself out if I'm not really paying attention. ::)
Your device mount point for the swap partition should probably be:
/dev/ad4s1b
The layout of the disk itself has not changed only where it is attached to the computer.
Steve
-
I assume you have renamed LAN as TPLINK24? But is still has the usual default LAN rules?
In LAN bridge:
TPLINK24 = LAN
BEDROOM = OPT1
NETGEAR16 = OPT2Not in LAN bridge:
GUESTDMZ = OPT 3TPLINK24 / LAN Still retains all default LAN rules and IP. I did change the IP of the switch to .1.2 so I could access it as its default IP is the same as pfsense's.
Where/how are you connected to the pfSense box when you set LAN to bridge0? I strongly advise you to be connected via an interface that isn't (and isn't going to be) part of the bridge when you set this up. I've set up bridging a number of times and I'm familiar with what pfSense will do and I still manage to lock myself out if I'm not really paying attention. ::)
I was using one of two wireless connections on separate interfaces, but they would both lock out when I was working on setting up the bridge. I've enabled another interface and used a cabled interface through that to get it semi working which, is where I'm at now.
Currently, after a few reboots I have the bridge semi functional. Currently, OPT1 / BEDROOM and OPT2 / NETGEAR16 are working fine with the bridge, but the LAN / TPLINK24 is not. At this point I've tested adding and removing the LAN interface from the bridge and it doesn't seem to make a difference in regards to functionality. LAN is setup as static IPV4, track interface IPV6, has the default IP, and is acting as the default DHCP server. When I attempt to set LAN to none / none it returns an error that LAN is acting as the default DHCP server and that requires a static IP.
At this point I rigged it to work by again running extra CAT5e cables between switches to connect them, and now it goes pfsense –> 16 port switch --> 5 port switch --> LAN ... = ridiculous. I'm guessing I should just create an additional interface with what was the default LAN network adapter, RE0 and add it to the bridge, but I didn't have to do that before to get it to work. As a side note I have 17 computers on the LAN interface so keeping that running is the number one priority right now.
Your device mount point for the swap partition should probably be:
/dev/ad4s1b
The layout of the disk itself has not changed only where it is attached to the computer.
Steve
Fixed, thank you.
-
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
![bridge tunables.jpg](/public/imported_attachments/1/bridge tunables.jpg)
![bridge tunables.jpg_thumb](/public/imported_attachments/1/bridge tunables.jpg_thumb) -
.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
-
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 .
-
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
-
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.
-
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
-
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?
-
http://en.wikipedia.org/wiki/IP_address#IPv4_private_addresses - read the Address autoconfiguration section. Windows sets those 169.254 addresses when it does not get a DHCP response within "timeout?" seconds. So that indicates that the Windows client DHCP requests are not getting through to the pfSense DHCP server (or the replies are not getting back).
-
That makes sense. Again, I'm new at this so what should I start looking in to resolve this?
-
Ok so this is good problem solving clues we have here. :)
So you can't ping other machines even across the same switch when both are receiving IP addresses in the 192.168.1.X subnet from pfSense. That is interesting because that traffic doesn't go through pfSense at all, or at least it it shouldn't. Hence whatever is causing those machines not respond to the pings is local.The ipconfig result from a Windows client shows, as Phil said, a load of interfaces with self assigned IP addresses along with one correctly assigned IP. I assume that you don't actually have 4 NICs in that box? What are showing up there as 'connections' I would interpret as what Windows does when it thinks you've connected it to a new wired network, it starts a new set of connection settings. Though I have no experience with Windows 8.
Theses two things together strongly point to my earlier hypothesis:@stephenw10:
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.
You said that you've tried a Kubuntu machine as well and that behaved similarly which seemed to rule this out but perhaps you didn't try receving pings with Kubuntu or it has a personal firewall on it.
Check that Windows firewall hasn't assigned the network as 'public'. Change it 'private' or trusted (it'e been a while ::)).
The cause of this is that the pfSense bridge MAC address can change. If you've rebooted your pfSense box check the output of ifconfig again to see if the MAC has changed. If it has then you can get around it by spoofing the MAC to something fixed. I had forgotten earlier but if you look back at my ifconfig output where my bridge has an obviously fake MAC that is because I spoofed it to that to get around this very problem! ;)
Steve
-
I haven't had a lot of time to work on this, but I have been twiddling with it every once in a while. My main issue right now is getting my power to actually stay on. I have a main shutoff that is going bad and a local place wants $225 for the breaker alone… ::) . Back to pinging issues though as I still haven't figured out this issue. This is from the same computer with Windows 8.1 .
Before reboot:
After reboot:
ipconfig /all returns:
You can see it isn't resetting the MAC address on reboot, but each time it has setup a new connection it is. All connections are set to Home and private within Windows firewall.
Pfsense has been rebooted about a million times as I had six power outages today alone. Here is a new 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 67.190.224.33 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>) 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 (none) status: no carrier 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></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,promisc,simplex,multicast></full-duplex></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>
This is the one I posted earlier:
$ 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>
-
The MAC I was referring to is on the pfSense bridge0 interface. It hasn't changed though which makes me think that's not the issue. Though you say the Windows box creates new connections every time pfSense is rebooted? It's hard to see but most of the connections on your Windows box appear to be TAP VPN connections rather than real Ethernet interfaces, does it actually have more than one real interface showing? Are those other interfaces something you have put there?
The only other thing I see that's different between your bridge setup and mine is that my bridge does not have an IPv6 address. Could this be an IPv6 issue? :-
Try setting the bridge interface to have IPv6 configuration type: 'none'.
Edit: The member interafce are also set to IPv6 type 'none'.
I can't see why that would be an issue to be honest but maybe something is trying route via IPv6.Steve