Multi LAN, WAN IPs and NAT problem
My first post here, and first of all would like to thank everyone for such a good resource here. It's helped solve lots of problems for me already.
I'm posting because I have a problem with a current setup, and wondering what I'm missing. Hopefully this is in the correct section, if not please move this post!
The setup I have is a dedicated server with OVH, which has been virtualised down with VMware. On this server there are a handful of VMs which are bridged out onto the public internet (e.g. web, email servers) with public IPs. I've also setup a pfSense VM and currently run 3 internal networks (each with various different virtualised systems, e.g. testing environments). These internal networks are then routed through the pfSense VM and out via the WAN. (Note the server VMs with public IPs do not run through this pfSense VM).
Currently I've set it up with an advanced NAT config, and multiple WAN IP aliases so that each of the three internal networks are allocated their own Public IP in effect. This is working great, no problems. For info the ranges and interfaces are:
From here I want to set up port forwards for the respective IPs, I've done this so far with the LAN interface which uses the true WAN interface IP and not an alias and this works absolutely fine, I can access the desired service from the internet no problem.
The trouble comes when I want to port forward using one of the WAN IP Aliases to one of the OPT interfaces. I've created the NAT rule, ensuring the destination public IP is correct, and I've checked the Firewall rules for each interface and added rules allowing the OPT1 and 2 interfaces to accept incoming packets. However I cannot access the desired service.
Is there anything obvious I've missed?
Also, while I'm here, because of the way OVH set things up their end, I have had to run these commands to get the pfSense VM to route packets to the upstream WAN gateway:
route add -net 188.xx.xx.254/32 -iface em0
route add default 188.xx.xx.254
This works fine and the pfSense VM can get out onto the internet perfectly, however if I change the config or pfSense updates I have to manually run these commands again before it can fine the correct upstream gateway. Is there a way to save these routes permenantly?
Many thanks in advance.
Why is your WAN and your upstream WAN gateway on different subnets?
This is due to the way OVH have set things up. A standard procedure for them from what I can gather.
The upstream gateway works as the pfSense VM can access the net, and so can the three internal networks, it's just the settings for this are lost on reboot or update etc.
I don't get it. What address do they route 178.xx.xx.xx to?
Seems that you would be better off putting an address on 188.xx.xx.xx on your WAN and using 178.xx.xx.xx as a routed subnet or VIPs. Does OVH have a network diagram of the product you have?
They route the 178.xx.xx.104 address (Which is the WAN IP of the the pfSense VM) to the main IP of the server which is in the subnet (188.xx.xx.172).
But because the server runs VMware this is the IP address of the management interface and the VMs with public IPs are bridged out onto the same network port.
I would give pfSense WAN an address on 188.xx.xx.xx and have them route the subnet to that. It doesn't make any sense to create an alias for the WAN subnet address instead of just making it the interface address.
I'm not sure I follow?
I'm using the IPs I've been assigned by OVH, I can't just assign it an IP address that I don't rent.
Again for clarification the IPs on the pfSense VM are:
WAN: 178.xx.xx.104/32 (Public IP for LAN)
WAN Alias 1: 178.xx.xx.195/32 (Public IP for OPT1)
WAN Alias 2: 178.xx.xx.136/32 (Public IP for OPT2)
Main server IP: 188.xx.xx.172/32
Upstream WAN Gateway: 188.xx.xx.254/32
Bare in mind this configuration isn't the problem I am having, the upstream WAN gateway works fine as the pfSense machine can sucessfully route packets to and from the internet, it's a problem with NAT/Firewall rules I would of thought (port forwards not working for OPT1 and OPT2).