Project

General

Profile

Actions

Bug #2744

closed

ARP related problem since upgrading

Added by Phil Lavin almost 12 years ago. Updated almost 12 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Routing
Target version:
-
Start date:
01/04/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

Description

I upgraded, by request of another issue, to the latest snapshot yesterday. We've had a strange issue arise.

The setup is such that the WAN interface is bridged with a "Firewall" interface such that devices on the "Firewall" interface can have firewall rules controlling their access. The subnet on WAN is 31.24.0.195/26. .195 is the assigned address. A device on the "Firewall" interface has 31.24.0.211/26. On resetting the networking for the .211 device, the pfsense router responds to an arp request for .195 with 00:90:7f:3f:cd:8f. This is the MAC address of the "Firewall" interface.

Some time later, the pfsense router requests the IP address of .211 from the MAC address of its WAN interface. This changes the MAC address of .195 in the arp table of .211 to 00:90:7f:3f:cd:91. This is the MAc address of the "WAN" interface.

This greatly confuses .211 and breaks internet connectivity.

Having discussed internally, I might indeed be doing it wrong in such that the IP should be assigned to an interface created from the BRIDGE0 "Network Port" but this is a setup that's worked without issue on stable and previous 2.1 snapshots so I wonder if there's a wider issue. Previous snapshot was compiled circa the end of October 2012.

I've attached a Wireshark compatible .cap of the ARPs. Suggested Wireshark filter is arp.dst.proto_ipv4 31.24.0.195 || arp.src.proto_ipv4 31.24.0.195


Files

dump.cap (77.7 KB) dump.cap Wireshark ARP Capture Phil Lavin, 01/04/2013 11:02 AM
Actions

Also available in: Atom PDF