Virtual IP issues in latest build (Feb2)



  • (I also have experienced this with several previous build in the past several weeks).

    When adding a virtual IP (as a Proxy ARP, IP Alias) fails to arp the MAC address of the WAN interface (ping does not work, even though there is a rule to specifically allow it). If I add it as "other"
    I can ping it (only from inside, and pfSense properly resolves the MAC address on arp-ing it).

    I've been trying to understand what is not happening correctly to allow me to add a virtual IP and NAT it (1:1) and forward traffic to it and originate traffic from the proper virtual IP.

    Is anyone else having a problem doing this on a recent build?



  • OK, I've read the ping behavior is normal according to this:
    http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F

    What I cannot seem to be able to do now in 2.0 is use virtual IP's on the WAN interface (1:1).

    Steps to reproduce:

    1. Created virtual IP (Proxy ARP) with 75.111.112.113

    2. Created 1:1 NAT
    WAN 75.111.112.113 192.168.1.130 * public address for 1:1 NAT

    3. Create Firewall>Rules>WAN
    TCP 75.111.112.113 * 192.168.1.130 80 (HTTP) * none

    Since I am using 1:1 there does not need to be any port forwards in NAT for this virtual IP. I ran a pcap of both interfaces. I see the WAN virtual getting the request to establish a session, nothing else. The LAN ip in the 1:1 NAT does not show any traffic destined for it.

    If this is the case, is it broken or did I perform the 1:1 NAT improperly?



  • Change the WAN interface IP temporarily to the virtual IP address that you will use in the 1:1 NAT, then set WAN IP back to original address. This sends the proper ARP to your ISP's router cache that your virtual IP should receive traffic. Don't know if this is your problem but I must always do this if I use proxy virtual IPs with my ISP which is AT&T DSL service. Search for my user name in the 1.2.3 forum if you want details on why this is required.


  • Rebel Alliance Developer Netgate

    If it's in the same subnet as your WAN, use a CARP type VIP. Otherwise use an IP Alias VIP.

    Both of those are "real" IPs instead of just proxy ARP, and may behave better with your upstream router.



  • None of these things work (changing the wan ip and back again, or using a carp ip).

    Is there anything wrong with my procedures? This does not seem to be an issue with 1.2.3, which is why I posted it here.



  • I confirm I face the same issue since a few days now.
    I have two WAN providers, one with MAC statically registered, and another one without.
    The one with the statically registered MAC mentions that it sees the vIP's MAC for the real IP and vice-versa !

    edit : and if i fail-over to my 1.2.3 pfsense, all is good



  • anyone else successfully using virtual IP's with NAt on 2.0? If so, a recent build? which one?



  • Yes, I am having exactly the same issue here. What I have noticed helps is if you remove and add back the IPAlias VIP.



  • @grazman:

    anyone else successfully using virtual IP's with NAt on 2.0? If so, a recent build? which one?

    I'm using carp type VIPs with dnat + aon and never had any problem.
    Currently I'm on Fri Feb 18 (i386)



  • I am on amd64 from 23rd Feb


  • Rebel Alliance Developer Netgate

    Anyone with an IP Alias issue, check the output of "ifconfig -a" when it's working and when it's failing, and see if there is a difference.

    Also be sure to check the system logs for anything around the time it started to fail.

    Tracking down something with a really vague problem report like this is difficult, we need a lot more information.

    I don't have any issues using 1:1 NAT currently, nor do most of the people I have worked with recently using 1:1 NAT on 2.0. It's a very common feature, and if it were broken in general, there would be lots of noise/yellling.

    I have seen some types fail in certain situations, but it had more to do with the switch and/or ISP gear plugged in on the WAN side than anything else.



  • Does anybody else suffering from those problem running in a virtual environment behind a vDS?


Log in to reply