Transparent firewall. Bridge? ProxyARP? Something else?
-
This is, I suppose, a bit of an architectural question.
In the attached image 814 is the current environment of a small customer. All IP's with 172.16-prefix are infact public addresses, but have been masked due to request from customer. They have a vmware box, which hosts a few VPS. They also have a Zentyal running to NAT a small network. No problem there.
But, they would like to have a box between the internet and the VPS-machines. Normally it would allow any/any. They pretty much just want to be able to filter traffic "in case of" so to speak. But, they would prefer not to have to change the IP's of the machines. Se image 815. In a perfect world, they wpuld like the same transparent box to be able to do "Normal NAT" for other segments.
Since I havent worked that much with pfSense (more familiar with Shorewall, Netscreen, TMG etc) I am not sure what the "best procedure" would be in this situation. In Shorewall I would probably just have gone with plain ProxyArp.
So, any hints and gotcha's are more then welcome.
-
What you're talking about is a layer 2 firewall. Don't do this. With IP aliases and 1-to-1 NAT you can leave these machines wide open to the internet if that's really what the customer wants, but change them to private IPs. It will make it easier to secure when they realize the error of their way as well as make it much easier to set up pfSense with multiple internal networks. If they insist on setting it up this way and you really think it's a good idea to have your name associated with a potential disaster here's how I would set it up:
- 3 interfaces: WAN (external facing 172.16.x.x) LAN (192.168.x.x) OPT1 (internal facing 172.16.x.x)
- Interfaces -> Assign, Bridges tab: Add a bridge between WAN and OPT1
- Interface Assignment tab: Add a new interface OPT2, assign bridge0 (this is where you assign your IP)
- Firewall -> rules, OPT2 tab: allow IPv4 type any source any destination 172.16.x.x network (you may need to add this rule to WAN and OPT1 interfaces as well)
- Allow IPv4 type any source 172.16.x.x destination any
- Configure LAN like normal people do
The 172.16.x.x machines would use the same gateway as the pfSense box (because it's not routing for them). It needs to be said again that this type of setup is never a good idea and changing interface IPs is not hard to do (honestly it takes 2 seconds) and neither is 1-to-1 NAT.
Just wondering if you're more familiar with other firewall platforms why are you using pfSense for this?
-
What you're talking about is a layer 2 firewall. Don't do this. With IP aliases and 1-to-1 NAT you can leave these machines wide open to the internet if that's really what the customer wants, but change them to private IPs. It will make it easier to secure when they realize the error of their way as well as make it much easier to set up pfSense with multiple internal networks. If they insist on setting it up this way and you really think it's a good idea to have your name associated with a potential disaster here's how I would set it up:
- 3 interfaces: WAN (external facing 172.16.x.x) LAN (192.168.x.x) OPT1 (internal facing 172.16.x.x)
- Interfaces -> Assign, Bridges tab: Add a bridge between WAN and OPT1
- Interface Assignment tab: Add a new interface OPT2, assign bridge0 (this is where you assign your IP)
- Firewall -> rules, OPT2 tab: allow IPv4 type any source any destination 172.16.x.x network (you may need to add this rule to WAN and OPT1 interfaces as well)
- Allow IPv4 type any source 172.16.x.x destination any
- Configure LAN like normal people do
The 172.16.x.x machines would use the same gateway as the pfSense box (because it's not routing for them). It needs to be said again that this type of setup is never a good idea and changing interface IPs is not hard to do (honestly it takes 2 seconds) and neither is 1-to-1 NAT.
Just wondering if you're more familiar with other firewall platforms why are you using pfSense for this?
I tried a bridging firewall, but i ran into a strange behaviour. A test machine on the inside pretty much only saw some muticast traffic from the outside. No unicast. And that was whitw a bidirectional any/any/any rule. Any hint to what may be amiss? Do i need to combine this with proxyarp?
Well, the reason for not chosing shorewall is that they want more of an "appliance" as compared to shorewall which is a bit more hard-core (from a user perspective)
-
Everything inbound from WAN is blocked by default, in a default LAN to WAN bridge, you'd only see layer 2 traffic coming in via WAN. You're permitting at least some traffic since you're seeing multicast, unless that's sourced inside the firewall. You would only see traffic inside the firewall destined to a MAC known to be inside the firewall, with the exception of broadcast and multicast traffic. VMware throws another complication in there in that it only sends traffic destined to the VM's own MAC to a VM by default. For a bridging firewall you need all MACs to go to the firewall, so every NIC on the firewall VM that is bridged must have promiscuous mode enabled on its port group.
Don't use proxy ARP at all in a bridged scenario, you'll just create IP conflicts.
-
@cmb:
For a bridging firewall you need all MACs to go to the firewall, so every NIC on the firewall VM that is bridged must have promiscuous mode enabled on its port group.
Yeah, I relalised that when I could not make the same scenario work with shorewall on the customers environment. I aparently enabled this for my lab environment many moons ago and simply forgot about it.
-
@cmb:
Don't use proxy ARP at all in a bridged scenario, you'll just create IP conflicts.
THe strange thing is… After having placed the virtual hardware in promiscuous mode it still did not work.
My CoLoc provider said that the MAC of my test machine behind the bridge did not show in their equipment.
So, for the heck of it i created a proxy arp VIP on my WAN interface, and that seem to have done the trick. Atleast it started working then?
-
That means the bridge isn't actually working, which in this case almost certainly means promiscuous mode on one or more port groups of the firewall isn't working for some reason. On rare occasions I've seen a host that wouldn't enable those settings properly until a host reboot, usually turning it off and back on suffices.
You don't want to leave it as is where there are two devices answering ARP for the same IP, as you're begging for a problem at some point with that. You effectively have an IP conflict, but one that can only be seen in part of the network since the bridge isn't working.
-
@cmb:
That means the bridge isn't actually working, which in this case almost certainly means promiscuous mode on one or more port groups of the firewall isn't working for some reason. On rare occasions I've seen a host that wouldn't enable those settings properly until a host reboot, usually turning it off and back on suffices.
You don't want to leave it as is where there are two devices answering ARP for the same IP, as you're begging for a problem at some point with that. You effectively have an IP conflict, but one that can only be seen in part of the network since the bridge isn't working.
THanks. I will definitely look into that.
Uhm, my WAN-side bridge interface has an IP. Does that change matters? Should i convert that to an "None" configuration and use a third interface for management?
-
@cmb:
On rare occasions I've seen a host that wouldn't enable those settings properly until a host reboot, usually turning it off and back on suffices.
How right you were.
Both the servers I have tried this on have the exact same patchlevel of ESXi. One is a Proliant DL380G6, the other a SuperMicro whitebox.
The proliant had no problem to enable promisc just by changing the setting. But the SM (which was the one i ran on primarily) did in fact require a reboot.