This article has been replaced by a new one using pfSense 2.0. The new setup is a lot simpler.
If you buy a VMware server and an IP block from OVH you will be surprised because the default gateway don't match the IP block. Even if this setup is unusual, it is valid and give full satisfaction.
There are some advantages to use this technique: this make the configuration of the hosting service provider routers a lot simpler (no need to setup an IP address for each underlying IP block, they can merge routes for adjacent IP blocks together) and the most important, this save one IP address.
Windows host accepts this unusual configuration and just work.
Linux host requires a little trick.
[root@fc6-pmx ~]# route add default gw 192.168.23.254
SIOCADDRT: Network is unreachable
Linux refuse to add the route because it don't know how to reach the gateway itself. Add the appropriate route for the gateway, before the default route, solves the problem.
[root@fc6-pmx ~]# route add -host 192.168.23.254 dev eth0
[root@fc6-pmx ~]# route add default gw 192.168.23.254
This works !
[root@fc6-pmx ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.23.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.23.254 0.0.0.0 UG 0 0 0 eth0
To configure a firewall, depending of the firewall, you will have to be imaginative !
If you want to use a pfSense firewall to protect this range of IPs, you will need a big trick. Even if the Web interface allows you to setup the gateway on a different network, the underlying system silently rejects this configuration.
If we come back to the basis of ethernet and IP networking and of what is a gateway, we will find an easy solution.
Here is an IP packet embedded in an ethernet frame.
The gateway is not the final destination of the IP packet, it is only the next hop. Its IP address never show up in the IP header ! This is the underlying ethernet layer that stores the MAC address of the gateway in its destination field. The gateway receives the packet because of the matching ethernet address and forward it to the next hop using the destination stored in the IP header.
Look at this schema ! This is the schema I used for testing the configuration.
All the IPs are from the Address Allocation for Private Internets ranges, even if some are supposed to be real Internet addresses, but it was for testing !
As said before, the IP address of the default gateway is not really necessary ! This address is not used by the routing process itself. Only its MAC address is really necessary to forward the packets to it. (I said it twice to be sure).
The trick is to assign a completely unrelated IP address to the WAN side. I choose 172.22.22.1 and 172.22.22.254 for the gateway. Then I link this gateway address to the MAC address of the real default gateway using a static ARP entry. This way the firewall will not use an ARP request but use this MAC address and send blindly outgoing packets to the good default gateway ! The default gateway has no way to guess how difficult it was (we had to cheat) to send packets to it :-) and will forward them as expected.
The usual command to setup a static ARP entry is :
# arp -S 172.22.22.254 00:15:F2:77:D3:15
To get this MAC address, you have no luck because pfSense don't have the required tools installed by default ! The last arping package is only for version 1.0.1 ! If you have already one working machine using this network, you can issue a ping to this gateway and then query your ARP table like this :
# ping 192.168.23.254
# arp -a -n (don't use -n on Windows host)
? (192.168.23.254) at 00:15:F2:77:D3:15 [ether] on eth0
00:15:F2:77:D3:15 is what you are looking fore. Unfortunately VMware ESXi don't have the arp command ! But if you insall the VMware vSphere Command-Line Interface it is possible to get this address using the command :
# esxcli --server=your_server --username=root --password=your_password network neighbor list
You will get something like :
Neighbor Mac Address vmknic Expiry(sec) State -------- ----------- ------ ----------- ----- 188.165.xxx.250 00:30:48:XX:XX:62 vmk0 1171 188.165.xxx.254 ec:30:91:XX:XX:c0 vmk0 1183
If you cannot run this command, you will need a Linux or Windows OS already working inside your VMware host, maybe the one you are using to configure your pfSense :-)
You have to configure the WAN before to add the static ARP entry !
To setup the static ARP entry, you can type the command in your pfSense console or use the WEB interface like this :
To hard-code the arp command, to have it working after a reboot, I will install the shellcmd package as soon as I have internet access !
And add this entry.
Here are the settings of my LAN in my pfSense firewall :
Then the settings of my DMZ (called OPT1 by pfSense) :
For packet coming or coming back from internet, the firewall will never answer to address 10.0.0.1 on the WAN side ! To force it to reply to ARP request for this address I have to add a Proxy ARP entry in my Virtual IP addresses.
The address is attached to the WAN interface.
But outgoing packets still leave the firewall with the wrong source address 172.22.22.1 and replies will never come back ! I need to masquerade the source address for outgoing packets ! First I need to disable Automatic outbound NAT rules generation in my pfSense firewall.
Then define the corresponding rules for the LAN and the firewall itself like this :
I can use 10.0.0.1 in this rule because I have already define a Proxy ARP Virtual IP !
Now, firewall and LAN can use the 10.0.0.1 to go out on the Internet.
I will assign the public address 10.0.0.2 to my virtual web server. First I create a virtual IP address like for 10.0.0.1 and all 10.0.0.X you want to use in your DMZ.
To use your DMZ you have to add fire-walling rules to allow packets to pass through between WAN and the DMZ (OPT1). Here for outgoing ...
.. and here for incoming packets !
That's it ! Now, your WEB server is accessible from the internet and from inside your LAN. If you have a LAN and have to expose some internal resources, here the way.
If you need to access some resources inside your LAN, you can easily NAT some ports of the address 10.0.0.1 to some of your internal hosts. If you need more addresses, add more Proxy ARP (identical to the one you have already setup above), and the appropriate Port forwarding rules ...
Double check if pfSense has added the equivalent filter rules and finally don't forget to setup the required outbound NAT rules to link your internal LAN address to the one you have setup in your Proxy ARP configuration.
If you need to manage IP fail-over inside this configuration, take a look at this post
The biggest advantage of this configuration is the use of routing instead of NAT to forward packets, this has a lot of advantages !
Hope this help !