Silicom PEG6I Six Port Gigabit PCIE
-
You don't need to include rules for DHCP they are already added by default if DHCP is enabled. For example:
@cat:allow access to DHCP server on LAN1
pass in quick on $LAN1 proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server"
pass in quick on $LAN1 proto udp from any port = 68 to 192.168.1.1 port = 67 label "allow access to DHCP server"
pass out quick on $LAN1 proto udp from 192.168.1.1 port = 67 to any port = 68 label "allow access to DHCP server"Steve
-
You don't need to include rules for DHCP they are already added by default if DHCP is enabled. For example:
OK, but a recent post http://forum.pfsense.org/index.php/topic,56848.msg303380.html#msg303380 (DHCP enabled on OPT1 but DHCP traffic apparently blocked by firewall) suggests they MIGHT be required. And I have memories of "unintuitive" behaviour in some earlier versions of pfSense, something like"specific firewall rules were not required for DHCP if DHCP server was enabled on a solitary interface BUT were required if DHCP server was enabled on a bridged interface and DHCP requests were to be accepted from a secondary member of the bridge."
-
Hmm, interesting thread. I certainly don't believe you are supposed to have to add dhcp rules. I have never needed to.
The user in that thread initially spotted dhcp requests in the firewall log, that would indicate a problem.
You can easily check by looking at the rules.debug file.Steve
-
Hi,
I have more information about my problem :
First of all, I changed my LAN interface to em0 and I removed rl0.
I finally saw my pfSense's interface em0 (10.0.1.1) with wireshark from my client(10.0.1.2 static). I could capture a couple of packets when I changed the ip address of em0. Here's what I could capture :
Here's some screenshots of these packets :
I also saw that my client had an invalid resolution for 10.0.1.1 via arp -a :
So I setted a static route with this command : arp -s 10.0.1.1 00-e0-ed-14-8b-aeAfter that I tried to ping my client (10.0.1.2) from my routeur (10.0.1.1) and here's what I've got :
Then I checked the states of the routes setted up on pfsense (Sorry for the picture, at that point I could not connect via ssh…):
I added a route directly to my client : 10.0.1.2 :
I started a ping from my routeur (10.0.1.1) to my client : 10.0.1.2 (The client was up and running and the firewall was disabled.):
EDIT : I forgot to say that, before i added this rule to PfSense, when I tried to ping my client, there's was no message like "Host is down." I could only see that the 3 packets that were sent were lost during the operation. There's probably a problem with these routes…
After that I started a ping my client to my routeur and I still had a message of "unreachable host"…I also putted the NIC in another computer (i386, the computer I used during these test is a amd), booted pfSense, setted up the interface and I got the exact same problem. (Moreover, pfsense freezed after a couple of minutes, but that's not my main issue...)
Regarding the configuration problem of the dhcp server(which is probably less important), here's a couple more infos :
Thank you!
-
First of all, I changed my LAN interface to em0 and I removed rl0.
Why? It is not clear to me that it is useful to change the pfSense LAN interface assignment from an apparently working physical interface to a physical interface you are having trouble with. At the least, it is likely to make it difficult to access your pfSense to capture information.
I finally saw my pfSense's interface em0 (10.0.1.1) with wireshark from my client(10.0.1.2 static). I could capture a couple of packets when I changed the ip address of em0.
Changed the IP address from … to ...? Based on the packet captures you provided did you change from 192.168.1.1 to 10.0.1.1?
The few times I have made major IP address changes to a pfSense box (changed the IP subnet of an interface with a static IP address) it has seemed to be necessary to reboot to clear out the memory of the ld configuration.
It is strange your route display for 10.0.1.0 doesn't display a network mask. That suggests to me the interface is not correctly configured.
-
First of all, I changed my LAN interface to em0 and I removed rl0.
Why? It is not clear to me that it is useful to change the pfSense LAN interface assignment from an apparently working physical interface to a physical interface you are having trouble with. At the least, it is likely to make it difficult to access your pfSense to capture information.
I changed it because I saw a post referring to specific firewall rules for the dhcp server. (It was only a test to avoid this possibility of bug.)
@wallabybob:I finally saw my pfSense's interface em0 (10.0.1.1) with wireshark from my client(10.0.1.2 static). I could capture a couple of packets when I changed the ip address of em0.
Changed the IP address from … to ...? Based on the packet captures you provided did you change from 192.168.1.1 to 10.0.1.1?
Yes, In that case it was a change from 192.168.1.1 to 10.0.1.1. (I did a couple of change to test some parameters but I rollback on everything.)
The few times I have made major IP address changes to a pfSense box (changed the IP subnet of an interface with a static IP address) it has seemed to be necessary to reboot to clear out the memory of the ld configuration.
It is strange your route display for 10.0.1.0 doesn't display a network mask. That suggests to me the interface is not correctly configured.
I'll try to force a mask at the end of this route.
Thank you. -
I'll try to force a mask at the end of this route.
How did you configure the interface? pfSense shell command ifconfig but forgot to specify a network mask?
-
I'll try to force a mask at the end of this route.
How did you configure the interface? pfSense shell command ifconfig but forgot to specify a network mask?
Hi,
here's the configuration of em0. Do you see any problem with this config?
The firewall rules of opt1 :
Here's the result of netstat -rn :
netstat -rn after a ping from the routeur (10.0.1.1) to the client(10.0.1.2):
The same thing with the WebConfigurator :
I am wondering : Does the "9b" is the good set of option for this card for em0? I am not familiar with these options.
Finally, here's the Gateway page :
EDIT :
Thank you!
Best Regards.(Let me know if you need more information!)
-
There have been reports of some combinations of drivers and NICs getting hardware checksumming wrong. So thanks for pointing out the options field.
How about starting a ping on the pfSense box and concurrently running a packet capture on the client. Do you see the ping? Does the packet capture report checksum problems? Does the client generate a response?
-
There have been reports of some combinations of drivers and NICs getting hardware checksumming wrong. So thanks for pointing out the options field.
How about starting a ping on the pfSense box and concurrently running a packet capture on the client. Do you see the ping? Does the packet capture report checksum problems? Does the client generate a response?
Edit : No, here's what i could capture. (arp request)
And the answer :
Does it looks like a driver problem?
I'm on the website of silicom right now and you need to be a "member" to get the driver. -
Hi,
I finally managed to compile the driver. What a painful experience…
The driver is correctly installed (and running) and I'm sure it's the right version but still, I have the same problem.
The last time I posted here the only thing I could see on my network was some ARP request. So I have decided to create some static arp resolution on my client and my router. I tried to ping my client from my router and this is what I could see (0/9 packets in/out is important):
BUT, here's what my client could see at the same time :
and this is the response to the ping command :
It looks like the NIC on my PfSense box can't read packets (?)…
I have to say that I have tried this on different interfaces (with no result) and I have tested this nic on my windows box and it worked perfectly. -
Any possibility you have the "bypass" variant of the card (PEG6BPi6) and it is operating in "bypass " mode (pairs of ports are internally linked so that traffic bypasses the host)? Apparently the PEG6BPi6 supports a variety of modes besides operating as a regular 6 port card see http://www.silicom-usa.com/Networking_Bypass_Adapters/PEG6BPi6-Six_Port_Copper_Gigabit_Ethernet_PCI_Express_Bypass_Server_Adapter_Intel_based_58
There is something "unusual" that your em0 is not receiving frames.
-
Ah, by-pass, yes my money's on that. :)
Looks like it has configurable options stored in an onboard eprom such that you should be able to boot it in a windows box, disable by-pass completely and it should then remember that setting in pfSense. If you have the bypass variant as Wallybob said.Steve
-
Any possibility you have the "bypass" variant of the card (PEG6BPi6) and it is operating in "bypass " mode (pairs of ports are internally linked so that traffic bypasses the host)? Apparently the PEG6BPi6 supports a variety of modes besides operating as a regular 6 port card see http://www.silicom-usa.com/Networking_Bypass_Adapters/PEG6BPi6-Six_Port_Copper_Gigabit_Ethernet_PCI_Express_Bypass_Server_Adapter_Intel_based_58
There is something "unusual" that your em0 is not receiving frames.
Hi, my card seems to be slightly different from a PEG6BPi6. (I have a "PEG6i".) I have never heard of a bypass mode and I'm not sure if my card offer this mode. I have to say, i had to format my pfsense box during the installation of the driver. Here's a new screenshot of the "mode" for em0, which is slightly different. (before it was in "9b" with <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>) But all other configuration are the same.
I will search how to remove the bypass mode. Thank you.</rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>
-
It will be easy to tell if you have a card with by-pass capability. It will have a number of small relays on it. Those are the small white rectangular things in this picture of the card:
If it does have by-pass it can be super confusing.
Steve
-
It will be easy to tell if you have a card with by-pass capability. It will have a number of small relays on it. Those are the small white rectangular things in this picture of the card:
If it does have by-pass it can be super confusing.
Steve
Hi Steve,
Here's a picture of my card. I do not see anything that suggest that my card supports "by-pass" function.
-
I agree. That's a shame because it would have very nicely fit all your symptoms. ::)
Steve
-
I agree. That's a shame because it would have very nicely fit all your symptoms. ::)
Steve
Well, i have to say that I have no idea what's going on with this…
I have never seen such a thing. -
From your recent screenshot of ifconfig output it appears you reverted to pfSense 2.0-RC1. Why?
For problems like this I would be inclined to stick with the version of pfSense built on the most up-to-date version of FreeBSD (currently 2.1-BETA1) to increase the likelihood that a similar problem had been seen by someone else, reported and fixed. -
From your recent screenshot of ifconfig output it appears you reverted to pfSense 2.0-RC1. Why?
For problems like this I would be inclined to stick with the version of pfSense built on the most up-to-date version of FreeBSD (currently 2.1-BETA1) to increase the likelihood that a similar problem had been seen by someone else, reported and fixed.Hi, as I mentioned earlier, I had to format my pfsense box while I was trying to install the driver and I used a cd that I had nearby. But you are right, I should have used the newest version. I'll start it over once more with version 2.0.2.
