Project

General

Profile

Actions

Bug #6834

closed

VIPs can cause hard-to-trace issues with dhcpd.conf

Added by Stilez y over 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Virtual IP Addresses
Target version:
-
Start date:
10/02/2016
Due date:
% Done:

0%

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

Description

I just hit a problem with my test version of pfSense, I'm not sure I can account for everything I saw, but I have a good idea what happened, and can probably provide enough detail to quick-fix whatever logical test was omitted that made it possible.

A couple of days ago I was playing with NAT, to try and understand how to get Outbound NAT to do what I gather it should (see forum post). In doing so I created 3 VIPs. This is the relevant config.xml

<vip> 
    <mode>ipalias</mode> 
    <interface>opt2</interface> 
    <uniqid>xxxxx</uniqid> 
    <descr><![CDATA[test1]]></descr> 
    <type>single</type> 
    <subnet_bits>32</subnet_bits> 
    <subnet>10.1.1.9</subnet> 
</vip> 
<vip> 
    <mode>ipalias</mode> 
    <interface>lan</interface> 
    <uniqid>xxxxx</uniqid> 
    <descr><![CDATA[test2]]></descr> 
    <type>single</type> 
    <subnet_bits>32</subnet_bits> 
    <subnet>192.168.1.9</subnet> 
</vip> 
<vip> 
    <mode>proxyarp</mode> 
    <interface>lan</interface> 
    <descr><![CDATA[test3]]></descr> 
    <type>single</type> 
    <subnet_bits>32</subnet_bits> 
    <subnet>192.168.1.10</subnet> 
</vip> 

The relevant interfaces were LAN on em1 (10.1.1.1/16) and OPT2 (192.168.1.1/16).

The documentation isn't clear about setting up a VIP for use in Outbound NAT, what type of VIP (alias or ARP proxy or something else), which subnet to choose the IP from and on which interface to define it, so I was trying things out - if someone can clarify that in the docs, it would also help a lot. But that's by the by as background.

(For info, the task I was trying to do was in order to translate the source address of the packet with src on the LAN subnet and dst on the OPT2 subnet, so that to the receiving device it appears to come from a different source IP.)

The attempt did nothing, the test platform appeared unaffected, all was fine for a good 2 days.

Then I used it to test the latest version of pfBlockerNG. I enabled the pfBlockerNG package and - blam!. Everything died. Within a second, I had an immediate loss of connectivity connection to the pfSense test platform from everything else connected to it.

To cut a long story short, it turned out that when I enabled pfBlocker it must have done something that modifying rules and aliases didn't, and either tried to restart dhcpd for the first time since the above VIps were created, or else somehow triggered a failure of dhcpd which tried to restart and kept failing. The error in the dhcpd log was: "Interface em1 [=LAN] matches multiple shared networks", which I eventually traced to one or more of the VIPs above - delete them and dhcpd was immediately happy again.

The issues that this suggests need fixing:

1. Clearly the root cause was that I was able to define an IP alias that caused a conflict for dhcpd and caused it to fail to start. I don't know which of the 3 VIPs was responsible, I deleted all 3 and that fixed it. Some code should be in the VIP assignment page (and other pages where interface IPs are assigned or modified?) so that when the user tries to change interface/IP assignments, create/modify VIPs, or change DHCP settings, in a way would trigger the underlying conflict, it's detected and config isn't modified.

2. I got back into the router by setting a static IP on a PC and entering the GUI. But no error or notification ever appeared on the GUI to tell me that dhcpd was having an issue and its startup had failed. When I found it was dhcpd in the log, and tried to restart (whether from status->services or services->dhcp), it failed and sat at ">" for "stopped, click to start", but I still never got an error on the GUI from the failed start attempts. So something's broken in GUI error reporting.

Actions #1

Updated by Jim Pingle over 4 years ago

  • Category set to Virtual IP Addresses
  • Status changed from New to Closed

I don't see anything actionable here. There is only so much we can do to prevent foot-shooting.

Actions

Also available in: Atom PDF