Proxyarp config help
-
- Set up the additional IPs as VIP at firewall>vip and choose type proxyARP
- Set up portforwards or even 1:1 NATs to your destinations inside your local subnets at firewall>NAT, portforward or 1:1 (depending what you prefer)
- Add firewall rules in case you want to use 1:1 NAT (portforward will generate the rules for you atomatically) to the internal IP of the destination client
- Apply all settings and be happy
-
I'd like to keep all form of NAT out of the picture for the proxyarp'ed hosts. Per my example, they would have addresses 1.1.1.14/27 and similar, with a default gateway of 1.1.1.1. NAT isn't used in the current config except for hosts that are in the 10.0.0.0/24 subnet.
Maybe I didn't make that clear in my first post. Sorry.
-
Then I don't know what you want to do with VIPs. You probably talk about a routing setup? Or maybe I don't understand your setup at all ???
-
I'm thinking you don't fully understand.
I have multiple hosts on the physical network that is connected to the DMZ interface. Some are in the same subnet as the DMZ interface address, but the rest are in the same subnet(s) as the WAN interface. The firewall is currently proxying ARP requests from one physical network to the other for the hosts I've defined…quite gracefully at that. Perhaps pfSense can't even do this?
It seems like basic functionality for a firewall to me...even more basic than a bridging firewall would be.
-
I don't think that setup will work with pfSense. You either can bridge interfaces or use NAT. VIPs are only thought to be additional IPs at an interface which then can be used to NAT them somewhere else (besides of CARP, which can be used for services running on the firewall directly or be natted). Maybe you can make your setup simply less comples. pfSense offers NAT reflection for portforwards (turn on at system>advanced) so you can access your internal clients by it's public IP.
-
I guess I'm confused, then. What is the proxyarp mechanism for? ???
Every OS that has any decent TCP/IP layer can have multiple addresses within the same subnet assigned to one physical interface. I thought the whole point of proxyarp was to respond on interface A as though you were the system on interface B…hence proxying an ARP request from a device on A to the device on B and vice versa.
Maybe proxyarp in the Linux world means something totally different :o
-
The way I described it is how pfSense makes use of proxyARP or at least how you can use it from the gui.
-
Huh…there doesn't seem to be any proxying at all going on in your example. Is there any more documentation on Proxyarp/Carp somewhere?
-
VIPs=Virtual IPs like CARP, ProxyARP, …see my former post:
VIPs are only thought to be additional IPs at an interface which then can be used to NAT them somewhere else (besides of CARP, which can be used for services running on the firewall directly or be natted).
-
I understand the concept of VIP…that's just a fancy name for a basic ability.
What I don't understand is the use of the term "proxyarp" (any VIP discussion aside) if all that can be done with it is outlined by your example. Your example consists of absolutely no proxying. :-[
One definition of the word "proxy" is "on behalf of". In your example, the firewall WAN interface is simply answering for multiple ARP requests with it's own or some derived MAC address. It's NOT answering an ARP request "on behalf of" another host that isn't part of the WAN physical network.
Surely other pfSense users have DMZ setups with multiple systems that occupy/respond on public IP's when, in fact, they're not actually physically connected to that subnet? I do this all the time with Linux and Sonicwall boxes. I'm believe the Netscreen products have similar functionality. Heck, I think even ISA has this capability. :-[
-
Patches accepted.
-
::) That's an easy out. ;)
I would submit a patch if
- I knew BSD like I do Linux
- I was a developer
Alas, neither is true.
-
::) That's an easy out. ;)
Not at all. We just don't have the resources to instantly code up solutions for every persons needs.
-
I realize the limited developer pool. Maybe I should try a different approach:
Should the naming of "proxyarp" in the VIP setup GUI be changed to something else so as to avoid confusion with something that might actually proxy arp requests? I mean, if it doesn't do that, it shouldn't be called that.
I suggest "additional" or "standard" or "non-primary" or "non-CARP" as more logical names based on my current understanding of how the function works. I know it's a small thing, but this really tripped me up and has kept me from trying to implement pfSense any further. As other people look to convert from other platforms to pfSense, any bit would help until the documentation is more complete.
-
That name was acquired from m0n0wall. They use the same terminiology and we have kept it the same so that there is no confusion for someone that is coming from m0n0wall.
-
Gotcha…I'll go bother them, then. ;D
-
So because m0n0wall used the wrong terminology, it continues?? Proxy ARP is a very specific capability in network routing - it is supposed to allow a device like a pfSense routing firewall to answer ARP requests on, say, its external interface, for IP addresses that already exist on devices 'behind' it. The device performing Proxy ARP answers ARP requests for a device for which it proxies, then routes traffic destined for that proxied IP to the device that actually bears that IP. It has nothing to do with NAT, nor even bridging.
j
-
Atleast for 1.0, yes.