ICMP NAT
-
And why can you not use 1:1?? Do you have more than 8?
Because, as I said, some IPs feed more than one internal PC.
As to why your vips are not answering icmp? What is your firewall rule that allows icmp state?
-
what version of pfsense are you running?
2.0.1-RELEASE (i386)
built on Mon Dec 12 19:00:03 EST 2011
FreeBSD 8.1-RELEASE-p6 -
IP alias and CARP VIPs will respond to ping from the firewall if that traffic isn't being forwarded elsewhere by 1:1 NAT.
-
Ah. I'm using Proxy ARP, which I guess is the problem.
-
"Because, as I said, some IPs feed more than one internal PC."
That doesn't really answer anything - do you have more than 8? if not then you could setup 1:1
-
OK, sorry, I see where you're heading.
There are 5 usable addresses (3 are used for subnet overheads and the router), and there are not currently 5 physical servers. But surely it is the number of protocol handlers that counts and there are more that 5 of those.
However, even if there were fewer protocol handlers I wouldn't want to lose the flexibility that 1:many gives us. For instance, if a protocol handler moves from one PC to another we just change the NAT redirection and off it goes. My client (and me, for that matter) can stick on a Slingbox and say he wants to see it from outside, I make up a rule and it is done.
When I developed CCTV for a client I could set up a redirect for his proprietary protocol and he'd connect right onto the box I was developinig and see the video, control the PTZ, etc. I didn't have to think twice about how to do that or whether I had enough IPs.
If we were using 1:1 we would have to juggle external IP addresses and then have DNS propogate those changes around.
Indeed, I use pfSense because it allows me to do great stuff like that, whereas if it were just 1:1 there are a zillion off-the-shelf boxes that will do the job for a tenth of the price a pfSense box costs.
Whilst I am grateful for y'all offering suggestions for workarounds, I feel that we're missing the bigger picture. Suppose I had 28 IP addresses - the essence of the problem wouldn't change because someone else would have only 3 (and that someone might be me with a different client or ISP). The answer to being able to ping an IP is not, I think, to have more of them or fewer servers.
-
Once you change from proxy arp, the IPs will ping. This has NOTHING to do with if the box that IP forwards too for that specific port is on or not.
I already went over my point about this.. if you send public.100 to private.52 icmp, how do you know if private.82 is online? Maybe you send public.100 port 80 to it?
Now your ok if you have less machines than you have public IPs. Because you can forward all 5 of your public to your 5 private. But what good does it do you if you have 28 private that your mixing and matching port forwards too from your 5 public IPs?
I just don't see a point of forwarding icmp in a 1:many setup – I can see the point of being able to ping the 1 sure. But once I setup a forward. Either the forward works that tells me the private is up, or it doesn't work - but the public 1 pings, so tells me box is down on inside if forward is not working. Atleast for my use, the ability to ping it or not ping it at this point is mute.
-
I already went over my point about this.. if you send public.100 to private.52 icmp, how do you know if private.82 is online?
Perhaps something got missed in translation :)
If I set public.100 icmp to go to private.52 icmp it's because I want to be able to ping private.52 on public.100. Private.82 is then not relevant because I didn't set up a forward to it, and I know I didn't. That's something I would have to bear in mind.
Let's suppose I am trying to get to www.bbc.co.uk and it's not working. So I ping www.bbc.co.uk to see if the problem is that end. I might try tracert to see how far along the line I can get before getting lost. I don't know the IP address of www.bbc.co.uk although I could look it up, but that's not relevant.
So, how on earth am I to know that I should ping engineering.bbcworks.co.uk instead? That might be the address of their router and no doubt their techies know about it, but I certainly don't.
Back to my setup. public.100:80 goes to private.52:80, and public.100:6745 goes to private:82:80. The public webserver on port 80 I want to respond to ping for other users trying to ping the webserver, whereas the private server on port 6745 is only used by me and I'm happy to know what I really need to do.
The fact that it can't be redirected everywhere isn't a problem. The fact that it can't be redirected somewhere is. As I said, having the router respond when it can't forward is fine, because ultimately the user debugging his link will see the public IP respond and know he can get this far.
I've had this problem before, where I do a tracert and it stops in the far ISP. Not knowing how the ISP is set up I don't know if that's an ISP problem or if it's the final hop before the destination IP.
-
"Back to my setup. public.100:80 goes to private.52:80, and public.100:6745 goes to private:82:80. The public webserver on port 80 I want to respond to ping for other users trying to ping the webserver"
But what does it matter - if public.100 answers ping. Its of little difference if its actually the webserver on private.52 answering the ping or the router. If the webpage does not work - this doesn't tell the user anything special.
Just like when you try and ping anything public like www.google.com or something - just because it answers ping does not mean it works, and just because it doesn't answer doesn't mean it doesn't work.
As long as public.100 answers you know that you have connectivity to the router. If public.100 answers icmp, you know that you have connectivity to what the public knows as the address. Be it the router that answers or the private.52 answers – if public.100:80 does not work - what extra info does it answering ping tell the user be it or even the admin.
Since its a different forward the admin has to still check if router is not forwarding or if private.82 is not listening on 80.
Just not seeing the point of pinging behind a 1:many nat to be honest. Now is it technically possible?? Not sure - have never had a need or desire to do such a thing.
-
But what does it matter - if public.100 answers ping
That would be OK. The issue is that it doesn't :)
A few posts up the implication is that it doesn't becuase I'm not using CARP. I don't think I want to use CARP because that is for multi-wan fail-over setups, and that isn't what I have. Should I ignore all that and just use the raw public IP address on my NAT rules?
Edit: OK, forget that question - I realise it's the wrong thing now. Unfortunately, I left my pfSense book at the client and he's not in a rush to post it back…
-
It does if you use the correct one - per the previous link I posted too, since your on 2.x according to
IP Alias
Available in version 2.0.
Adds extra IP addresses to an interface.
Can be used by the firewall itself to run services or be forwarded.
Will respond to ICMP ping if allowed by firewall rules.http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F
-
Yes, my problem now is converting from one to the other. I can't create an IP alias when there is already a virtual IP with that address. Even if I change all references to a specific host address, I can't delete the PARP entry because the address is still referenced by NAT. It looks like I have to vape everything and start again, which I can't do remotely.
Edit: Duh! I can just go in and edit it, and then it works :)
Sorry for the aggro of getting to this point. I appreciate your help and patience!
-
No problem - so your all good now?
-
Yes, thanks. I am sated :)
-
If you still want to forward it, it should be fairly easy to just add the option. Open /usr/local/www/firewall_nat_edit.php, find the string "TCP UDP TCP/UDP GRE ESP" and simply add ICMP to the list, like this: "TCP UDP TCP/UDP GRE ESP ICMP" I don't think there's anything more to it than that. Another way would be to manually change the protocol to icmp in the configuration.
-
Thanks!
Ummm… if it's that simple, is there some compelling reason for not allowing it in a distribution? Whilst my immediate problem is resolved, it would be great to be able to ping an actual machine behind a NAT router.
-