Migrating from iptables to Pfsense unsuccessful

  • Hello pfsense gurus,

    I have an issue with setting up Pfsense in place of an old iptables firewall configuration. Let me walk you through the current setup (iptables) that I was assigned to migrate from.

    So, basically it is pretty much straight forward. The iptables box has three interfaces (wan, dmz and lan), and are assigned as follows
    wan -
    dmz -
    lan -

    On the dmz lan there are two servers (vpn and web server, with public IPs in the same subnet). The rules configured are also pretty simple: on Lan allow everthing to exit the network, and on WAN allow icmp, http/https destined to the web server and vpn traffic (isakmp, gre, esp) destined to the vpn server.

    The firewall is a VM on ESXi host, as well as my Pfsense box is also built in a VM.

    As you can see from the IP addressing above, dmz and wan are using the same interface, which posed a problem with Pfsense, as you can't assign the same IP on two different interfaces. So I had to assign dmz an ip address of and make that the default gateway of the dmz servers. The Pfsense firewall rules are as follows:
    on WAN: allow icmp from * to WAN_IP, DMZ_servers
                  allow http from * to web_server
                  allow GRE, ESP, UDP from * to VPN_server on ports 500,1723,1701,4500

    on DMZ: allow IPv4* from * to * (allowing everything)

    on LAN: allow IPv4* from * to *  (allowing everything)

    The end result after disconnecting the old iptables and switching over to Pfsense was that clients could normally access the Internet and connect to the dmz servers from the internal network, but are unable to connect from outside to the web server, or the vpn server. Ping, http and vpn traffic couldn't reach the DMZ.

    I don't know if there is certain rules I am missing here, or is it matter of gateway issue, or what. I have attached a simple diagram of what the network looks like. Let me know if you need any more information from my end in helping you determine the cause. Thank you guys

  • You have to bridge WAN and DMZ together if you want to use the same subnet on both of them. The routing code in FreeBSD refuses to work if you try to route traffic between two interfaces with overlapping or identical subnets.

  • Thanks for the tip. So I assigned one available physical interface as OPT2, then I went to Interfaces -> Bridges and added WAN and DMZ to Bridge0. Then I returned to the newly created OPT2 and assign it to Bridge0. In regards to the IP addressing scheme and the physical connection, what should I change so that my dmz and wan share the same IP address, also do I use the OPT2 physical port?

  • Assign an address on the WAN interface but leave the interface (DMZ) that is bridged to it without an address, it's not necessary to have an address on the other interface of the bridge. Then you just set up the machines on the DMZ network using addresses from the same address space as the WAN network is using.

  • LAYER 8 Moderator

    But if he bridges DMZ and WAN together he can't use filters between them. I don't get the picture above in the first place as it makes no real sense to me. If you want your machines in the DMZ to have public IPs, you could also go the BiNAT way (1:1 NAT) or cut a piece of the public IP space out and assign it to the DMZ (if that's possible with your upstream provider). Bridging DMZ and WAN together somehow defeats the purpose in using a DMZ.


  • Filtering works just fine with bridging, there is no real difference in filtering between a bridged and routed/natted setups. You of course have to be aware of where the traffic is originating to understand how to write your firewall rules. As for "defeating the purpose of DMZ", I don't understand what you mean by that? With bridging you can use public IPs directly on the DMZ hosts and you don't have play tricks with any kind on NAT/RDR/etc.

  • LAYER 8 Moderator

    I misread the filtering part. My bad. And of course with your setup you can use your IPs directly in your DMZ. But you can do that, too, if you just split your network into a DMZ segment or route the whole subnet over a transfer network (what is most common imho). I just don't see the big benefit in bridging WAN and DMZ together.

    As for tricks of any kind: I don't see NAT or RDRs as "tricks" but merely a possibility to simply use public IPs on (mostly virtual) servers (today) very easily. And with the added possibility to use private IPs for the servers itself, I can easily clone a machine, do some changes and just change my redirection rule to it to have it live. No configuration to a live IP, no poweroff of the old system, just seamless switch-over and switch-back to test changes.
    And even with routing a subset or network to the DMZ segment I feel more flexible in usage as the bridge configuration.

    But as you are migrating, that's perhaps unwanted or impossible to do, so I'll shut up ;) I was just curious, why someone would set it up this way.


  • Thanks for the help guys. Bridging the interfaces is exactly what I needed. I was able to route traffic with no problem and have all of my rules setup as I wanted them. We can close this topic now

Log in to reply