ICMP NAT
-
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.
-