Migration from physical 1.2.3 to virtua 2.0.1 not working



  • Hello,

    we are working for a school authority in Germany.

    we have a problem using pfsense 2.0.1 in a virtualized environment (vmware esxi 5.0).

    Our network routes 80 school-locations in private networks (10.0.0.0/8) to one router, who is connected to our LAN (192.168.50.0/24).

    The pfsense has a LAN-Interface (192.168.50.13/32), a DMZ-Interface (192.168.70.10/32) and a WAN-Interface (219.31.177.194/28). We have 48 official IP-addresses, 16 of them in the network, the WAN-Interface belongs to (219.31.177.0/28), 32 of them in a different network (219.31.175.0/27).

    The pfsense interfaces are connected to different vswitches of the ESXi Host.

    All requests to the internet are routed through a central proxy-server, NATted to a certain WAN-address. In our DMZ are the proxy-server, a web-server and a mail-server.
    With our rules imported from a physical pfsense 1.2.3 firewall, every traffic into the internet works, from everywhere. The webserver can be reached, internally and externally. The mailserver works perfectly.

    Some of the school-clients have certain roles, like security-systems, and are NATted to certain virtual ip-addresses in the "second" ip-address section, the one which has netmask 27 (the physical network interface is connected to the section with netmask 28).

    With our physical pfsense 1.2.3 this works perfectly. The new virtualized pfsense 2.0.1 doesn't react on any request to such an internal system/address from outside. Rules - if pass or block, always logged - do not show up in the system log.

    So, with this - kind of a long - explanation:

    • does anybody has a hint or solution?

    • we read that putting the vmnics into promiscous mode might help?

    • or do we need a kind of static route from the WAN-interface (netmask 28) to our inner ip-addresses (10.0.0.0/8)?

    • perhaps some differences of the pfsense versions?

    Any kind of help is very much appreciated …

    Thanks in advance ...

    Peter Barth


Log in to reply