• This has been discussed before (here) with the result that the chap wanting to NAT ICMP is an idiot. I don't think this is a valid reason for not allowing ICMP NAT - it's that kind of thinking that dumps telnet ('for the users own protection') from distros.

    Anyway, I have just moved a client from one office to another, and things were not going quite to plan. Specifically, VPN was AWOL and the client was trying to ping vpn.domain to deteremine where the problem is. Of course, that resolved to one of 7 IP's that aren't the router IP so nothing replied. I tried to point out that the router /was/ replying from the IP it's sitting at (actually mail.domain) but that obviously isn't the VPN address so meant nothing.

    The client trusts me (which is why I'm doing this stuff) but, even so, in the heat of needing a fix he failed to grasp why I ask him to ping one thing when attempting to fix another (and explcitly saying ping is not a good indicator of a connection…).

    For me, when I am sitting here remotely and have no idea what is going on with his LAN, I would lurve to be able to ping a LAN device to find out if the thing is alive. Using the client protocol is wrong when the client protocol is the thing being suspected of not working. Adding another variable (is the machine there in the first place) isn't the way to resolve stuff.

    What I would like to ask for is one, or preferably both, of these solutions:

    1. Allow ICMP as a protocol in the NAT config. My understanding is that FreeBSD will do the biz if you only allow the user to tell it to.

    2. Allow pfSense to respond to ping on any IP address going through it (that is, in my case pfSense would return a 'hello I am here' on mail.domain and vpn.domain).

    Thank you.

  • LAYER 8 Global Moderator

    So this vpn.domain is behind the NAT?  Or is a routed segment behind pfsense?

    if a routed segment, then you would just need to allow icmp to that segment at the firewall.  Example is this is my routed /64 ipv6 range - I can ping any ipv6 client behind pfsense that is alive and allows ping.

    Are you wanting to use 1:1 Nat?  Then again those would allow ping to those specific 7 IPs that your doing 1:1 nat to some box behind pfsense.

    But how do you think you can nat icmp to more than 1 IP behind the nat?  Why not just ping the IP of pfsense wan IP in that case?  If you forwarded the icmp to inside - how do you check if pfsense answering?

    Why don't you just connect to his pfsense box directly (he should allow that if he wants remote help)  Then you ping whatever you want from pfsense to the inside lan.

  • The incoming broadband has 8 IPs allocated to it. The router running pfSense uses NAT to send incoming http on port 80, for instance, on one IP to a specific server on the LAN, and port 80 on another IP to a different server. I guess this is a routed segment behind pfSense?

    OK, so the range of IP's would be, say, 93.x.x.97 to 93.x.x.102, and in the DNS for the domain has vpn.domain, which resolves to .101, and mail.domain, which resolves to .97. The router is on .97.

    Are you wanting to use 1:1 Nat?

    No. My understanding is that pfSense will then forward everything to a specific LAN IP as if the router wasn't there. That's not what I want, because some ports on that address will go to a different LAN PC.

    how do you think you can nat icmp to more than 1 IP behind the nat?

    Just like any other protocol or port, when I set up the NAT entry I specify what LAN IP it goes to. If I want it to go to the VPN server then I will use the LAN IP of that. If I'd rather it goes to the web server I will use the LAN IP of that instead.

    In many cases, I suspect it is not the specific machine that handles it that's important, but that something handles it. In that case I might elect to route ICMP on a specific external IP to the router IP, so the router replies. If we could just have ICMP in the list of protocols on the NAT page I can do all or any of this as I want or need to.

    Why don't you just connect to his pfsense box directly

    In the first place because it is HIM that is doing the ping. He knows enough that he can use ping to find out if something is there, but not enough to realise that it won't work on a pfSense setup. So he has a problem connecting to VPN, tries ping the correct IP (via the URL) then contacts me to say the server is dead. It turns out to be his phone that's the problem (used tethered as a modem) but ping tellls him it's the server. Why should he know to ping some completely different thing when it's obvious to him what he should be pinging?

    Secondly, I use Cacti to monitor stuff and one of the things it does is ping devices to a) see if they are there, and b) check the link congestion. That isn't going to log onto his pfSens box and run a ping command…

    Thirdly, I use PingPlotter for finding flaky connections and stuff. The pfSense ping facility isn't comparable in any way with tools like that.

    Without trying to be argumentative or aggressive, can I ask what the problem is with adding ICMP? It does seem as if it's more than a technical issue.

  • LAYER 8 Global Moderator

    No if the 8 ips are on the wan interface of pfsense - that is not a routed segment.  So you have virtual IPs on the wan interface for these 8 different IPs.

    if you setup 1:1 nat for 8 machines behind pfsense - then you could do what you want.  in a 1:1 Nat setup all traffic would be sent to the specfic IP that is setup as the 1:1 for example

    public.114 goes to
    public.115 goes to

    You would then just allow what ports or protocols you want to allow to the private IP.  ICMP could be allowed or denied.

    But if your doing a 1:many type nat, which is default - then no you can not forward icmp, its not really a port its a protocol.

    So for example you could have public.114 port 80 sent to private.132 and port 22 sent to private.52, and public.114 port 21 sent to private.89

    Now since all 8 of your ips reside on your pfsense wan, then you could allow for all 8 of them to respond to icmp or not.  But in a 1:many sort of nat.  Which one do you send icmp to? .132, .52 or .89?  If you send it to .89 that does not mean that .52 is working, etc.

    So the question is for your 8 public IPs how many private IPs use these 8 public IPs?  If 8 or less then just setup 1:1 nat and firewall the stuff you want to allow or deny to these IPs.

    So to help you solve  your issue, we need to understand how your natting, be it 1:many or napt or 1:1?  Or if your 8 IPs are actually routed inside and your boxes inside actually have public IPs assigned to their interfaces or private IPs?

  • So you have virtual IPs on the wan interface


    If you setup 1:1 nat for 8 machines behind pfsense - then you could do what you want

    Sorry, but I don't think I can. As I said, for a specific external IP one port will going to one internal PC and another port will go to a different internal PC. It is not a 1 to 1 mapping.

    then no you can not forward icmp, its not really a port its a protocol

    Surely, technically, it must be forwardable since it is just another packet, and it is routable. My understanding from other threads is that the underlying pfSense software will do it, but we have no way to say to it to do it. Is that wrong?

    you could allow for all 8 of them to respond to icmp or not

    Failing the ability to NAT ICMP that would be the next best option. I honestly can't understand why it isn't happning like that already.

    Which one do you send icmp to?

    That's what the NAT entry tells you, surely. When you set it up there is a field "Redirect target IP" and you fill that in with the appropriate IP. The pfSense developers don't have to worry about this any more than they do for any other protocol. It is me who fills in that field (which already exists and is used) and it is me who determines what machine I want it to go to. I didn't think this was tricky to figure out and I've said it more than once - am I missing something which makes it impractical?

    we need to understand how your natting

    It is 1:many, the default for pfSense. I can't use 1:1

  • LAYER 8 Global Moderator

    And why can you not use 1:1??  Do you have more than 8?

    I have never ever ever seen a 1:many nat that supported forwarding icmp.

    As to why your vips are not answering icmp?  What is your firewall rule that allows icmp state?

  • LAYER 8 Global Moderator

    what version of pfsense are you running?

    From here

    A vip before 2 will not respond to icmp.

  • @johnpoz:

    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?

  • @johnpoz:

    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.

  • LAYER 8 Global Moderator

    "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.

  • LAYER 8 Global Moderator

    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.

  • LAYER 8 Global Moderator

    "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…

  • LAYER 8 Global Moderator

    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.


  • 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!

  • LAYER 8 Global Moderator

    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.

  • @PurpleOfPants:

    if it's that simple…

    For the avoidance of doubt, it is that simple. Fantastic  :-*

Log in to reply