Silicom PEG6I Six Port Gigabit PCIE
-
Does anyone have any idea about that?
After major changes to firewall rules it is sometimes necessary to reset firewall states: See Diagnostics -> States and click on Reset States tab, read the explanation then click on Reset button.
Firewall rules have more parameters than you have provided. Please post a screen shot showing the firewall rule(s) on OPT1.
What was reported when you tried to ping 10.0.1.1 from a computer connected to the OPT1 interface? (Please post command and response. They are almost always much more informative than the executive summary "can't ping".)
Do you see any of your ping attempts reported in the Firewall log? (See Status -> System Logs, click on Firewall tab.)
Hi,
I have completed the instructions you gave me yesterday and here's what i've got :
First of all, I went to the "Diagnostic States" and clicked the "Reset" button in the "Reset States" tab.
Here's a screenshot of my firewall rules. As you can see, I have created 2 rules instead of one. (Because I wanted to see which rules was associate with every log. The "log" checkbox is enabled.)
Here's a screenshot of the ping commands while connected as 10.0.1.2 : I have also included what Wireshark could capture during the same time.
Finally, the firewall logs are empty. Here's a screenshot. (I do not understand why it's empty).
-
You have multiple problems. Thanks for including the Wireshark capture.
1. Your Windows systems is sending ARP requests to find out the MAC address of the system with IP address 10.0.1.1. It is not getting a response hence it doesn't know what MAC address to send to in order for traffic to get to 10.0.1.1. Until this is fixed you won't see traffic on this interface in the firewall log.
2. Your firewall rules don't allow DHCP requests: Source IP = 0.0.0.0 and Destination IP = 255.255.255.255
I suggest you perform a packet capture on pfSense while a ping is running on the Windows box. Do you see the ARP requests? If not, it would appear something is "strange" with your switch. Is it a "managed" switch - perhaps it was previously configured for VLANs or some sort of access control? You could also try pinging 10.0.1.2 from pfSense to see what happens.
-
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.
