Please provide a network drawing.
I suspect you have a arp leak or a switch that needs to be restarted to
clear its arp cache. Restart switche (s) without nothing connected and add
the cetos and pfsense only and only after you have cleared both units arp
cache (arp -d). Then take it from there.

HTH.

- LSF
 11. juli 2014 21:57 skrev "Stefan Maerz" <
stefan.ma...@thecommunitypartnership.org> følgende:

> On 7/11/2014 2:03 PM, Stefan Maerz wrote:
>
>> On 7/10/2014 7:52 PM, Stefan Maerz wrote:
>>
>>>
>>> Hi everyone,
>>>
>>> I have a problem I have been unable to solve all day (literally *all*
>>> day).
>>>
>>> My pfSense box has two LAN interfaces and a WAN interface. A CentOS 7.0
>>> server is giving me grief on one of the Subnets when configured as static
>>> or dynamic.
>>>
>>> When I put the problematic CentOS box on the other subnet (and change
>>> corresponding host network configurations), it works. The CentOS box also
>>> works when I put it on my trustworthy Linksys WRT router (again, changing
>>> host network settings along the way). To me this smelled of a firewall
>>> problem, but there is nothing logged and I have both LAN interfaces set up
>>> to pass everything. Secondly I looked at DHCP for possible DHCP addressing
>>> conflicts, but the DHCP server is disabled on this subnet. TCPdump reveals
>>> that literally nothing is making it to the gateway interface, however at
>>> the same time the activity light on the interface blinks corresponding to
>>> my pings (there is no other traffic).
>>>
>>> Further confusing me is that I am able to get a static IP from other
>>> devices when I plug them into the problematic subnet. Basically this single
>>> device does not work on this single subnet and that is the only problem.
>>> Other devices are fine on this subnet and this device is fine on other
>>> subnets. ...?
>>>
>>> It is also worth noting that all the link lights are lighting up and the
>>> cables and switch have been tested to be working correctly. Nothing that I
>>> can see looks out of place in pfSense's logs.
>>>
>>> Here are my host configuration files, all generated by CentOS's nmtui
>>> utility. I tried my own manual configurations with the same results (not
>>> working):http://pastebin.com/HFYYTG09(possible typos -- this is hand
>>> written, my apologies if that is the case)
>>>
>>> I am at a loss and have been at this all day. pfSense has so little to
>>> configure that I'm not really sure what I could have done wrong. I feel
>>> like it is something really simple that I missed. Anyone have
>>> recommendations on how to troubleshoot?
>>>
>>> Best Regards,
>>> -Stefan
>>>
>>>  Hello again,
>>
>> I have been looking around. I found something interesting in my ARP
>> table. For some reason my Windows 7 Admin workstation has two IP addresses
>> assigned to it. Stranger yet is that one of the addresses a) is not on the
>> correct subnet, and b) is the gateway address for the SRV subnet (the
>> problematic subnet).
>>
>> Additionally there is nothing in the problematic CentOS box's ARP table.
>>
>> To me this would indicate that CentOS is trying to reach its gateway but
>> pfSense is telling it that its gateway is on the wrong subnet (my Windows
>> Admin Computer).
>>
>> I unplugged everything from the SRV (problematic) subnet and unplugged
>> the ADMINISTRATOR computer then manually flushed pfSense's ARP table (arp
>> -da). This removes the 10.145.1.38 entry, but the incorrect 10.144.1.1
>> entry is persistent.
>>
>> How can I fix this? Is something misconfigured? Am I misunderstanding
>> something? Is it a pfSense bug?
>>
>> See pictures:
>> https://db.tt/4Q6skpiF -- pfSense ARP table (some data sanitized)
>> https://db.tt/coWT9GoB -- Settings on ADMINISTRATOR PC
>>
>> I am greatly appreciative of any help.
>>
>> Best Regards,
>> -Stefan
>>
> I believe I have indeed confirmed something is indeed wrong with ARP.
>
> Here is a TCP dump session from the pfSense Box*:
> http://pastebin.com/zyVpPkcD
>
> As you can see it is looping through ARP. Line 6 is pointing my CentOS box
> at a MAC address on a separate subnet.
>
> So I suppose my question is now, how do you troubleshoot ARP? Isn't it
> supposed to just work? What am I doing wrong?
>
> I also have a remote site that could benefit from this knowledge*:
> https://db.tt/5xKvBZBb
>
> Best Regards,
> -Stefan
>
> *Data is sanitized
> _______________________________________________
> List mailing list
> List@lists.pfsense.org
> https://lists.pfsense.org/mailman/listinfo/list
>
_______________________________________________
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Reply via email to