Proxy Arp - Whats My IP always shows WAN IF



  • I'v used Linux firewalls before and thought pfSense looked like a slick
    product (I like the no HD option).

    I decided to start with a very basic setup until I knew the product better.

    -Config-

    ISP Router -  216.50.168.33/27

    WAN static routable IP  216.50.168.34/27

    LAN 10.10.01.1/24 w/ DHCP & DNS Forwarder

    Disable userland FTP-Proxy checked for both.

    No aliases

    NAT:

    1:1 set as:
      WAN    216.50.168.37/32    10.10.10.2/32

    Rules:

    Default LAN -> net any is there

    Virtual IP:

    Proxy ARP set up as follows:
    IF - WAN
    IP address - single address  216.50.168.37/32

    Nothing else set.

    According to documentation visiting whatismyip.com should return the IP
    216.50.168.37 but it returns 216.50.168.34 and so does www.whatsmyip.org.

    Is this an ARP caching issue?  If so, who might the culprit be?  If not,
    where did I go wrong?  I've tryed this using 2 different ISP routers on 2 different T1s.

    As I understand then documentation Proxy ARP is the main (recommended?) way
    for issuing routable IPs to hosts when less than a full subnet is all that
    is available.  If there is a cleaner way, I'd like to know.



  • Maybe you did things in the wrong order. You first need the proxy-arp vip, then assign the 1:1 nat. Did you try to reboot? Also try to reset the states at diagnostics>states, reset states. In case there is still a state it won't create the new mapping until  it times out or you reset the states.



  • This is kind of stupid.  1:1 (binat) NATs are entered in rules.debug after normal NAT entries.  This means that normal NAT occurs first sigh.  I do believe you've found a bug.  In the meantime, a hack to get around your issue is to enabled adv. outbound nat, and add a rule for "no nat" for your IP and put it ahead of the other NAT entries.  I think that'll solve your issue.  I've filed ticket 1146 http://cvstrac.pfsense.com/tktview?tn=1146 for this.  Thanks



  • OK, this was only a bug in the HEAD branch :-/  Can you send me your /tmp/rules.debug - email to billm at pfsense.com.  Thanks

    –Bill



  • Disregard, I think you were hit by the check_reload_status bug.  Reboot or run:

    
    /usr/bin/nice -n20 /usr/local/sbin/check_reload_status 2>/dev/null
    /etc/rc.filter_configure_sync
    
    

    from the command prompt.  That should fix your rules.

    –Bill



  • Sorry I didn't notice the reply until now, I had to set aside pfSense and temporarly use something else to get a IIS site up.

    First, I'll try to keep in mind the 'order of operations'.

    Second, I'm glad I was able to help find a bug.  I hope the fix made it to 1.0 stable.

    I plan on testing 1.0 in the near future.

    Thanks to all who replied.


Log in to reply