Ping through firewall
Tom
someone ping my computers sitting behind the firewall unless something
on my side is compromised?
I have a home network with several computers and until recently never
get any alerts to pings etc from beyond my router. At this point i am
more curious than alarmed, but perhaps i should be concerned.
I have recently installed a music server linux box(i do not have login
rights unfortunately) and tried to use tcpdump from my other linux box
to trace the path of these packets w/o any luck.
Thanks,
Tom
David Schwartz
> My question is if I am using a firewall(a Netgear wgt624) how can
> someone ping my computers sitting behind the firewall unless something
> on my side is compromised?
Is the firewall set to block pings?
DS
Char Jackson
wrote:
>My question is if I am using a firewall(a Netgear wgt624)
I'd probably call it a wireless router.
> how can
>someone ping my computers sitting behind the firewall unless something
>on my side is compromised?
Are they truly getting a ping response from one of your NAT'ed PC's,
or is it the router that's responding? Is the router configured to
forward traffic to the PC that's supposedly responding? Is that PC
configured to be in the router's 'DMZ' (which is just another way of
saying all traffic is forwarded to that address)?
>I have a home network with several computers and until recently never
>get any alerts to pings etc from beyond my router. At this point i am
>more curious than alarmed, but perhaps i should be concerned.
>
>I have recently installed a music server linux box(i do not have login
>rights unfortunately) and tried to use tcpdump from my other linux box
>to trace the path of these packets w/o any luck.
Is the music server on the PC that's responding to pings?
Tom
>
> I'd probably call it a wireless router.
allowed)
and to not respond to ping.
>
> Are they truly getting a ping response from one of your NAT'ed PC's,
> or is it the router that's responding? Is the router configured to
> forward traffic to the PC that's supposedly responding? Is that PC
> configured to be in the router's 'DMZ' (which is just another way of
> saying all traffic is forwarded to that address)?
>
The PC(Vista) is not in a DMZ. I just happened to scan my McAfee logs
and saw the
warnings about the pings.
>
> >I have recently installed a music server linux box(i do not have login
> >rights unfortunately) and tried to use tcpdump from my other linux box
> >to trace the path of these packets w/o any luck.
>
> Is the music server on the PC that's responding to pings?
The music server is a separate Linux box, it is the Vista PC which is
responding or at least getting pinged.
David Schwartz
> It is wireless configured w/ access list(only my wireless devices
> allowed)
> and to not respond to ping.
Right, but is it configured to block pings that attempt to pass
through it?
> The music server is a separate Linux box, it is the Vista PC which is
> responding or at least getting pinged.
Is the firewall configured to block such pings?
Perhaps you are under the mistaken impression that NAT is some kind of
firewall all by itself. The goal of NAT is to make things *work* not
to make things not work. If a NAT device can pass the ping, it will
and should, unless configured not to.
DS
Tom
Thanks for the responses, it looks like I should take this up in a
netgear
forum if I want to understand the NAT functionality.
Tom
Barry Margolin
<c49d06ac-126d-4bdd...@t11g2000prh.googlegroups.com>,
David Schwartz <dav...@webmaster.com> wrote:
> Perhaps you are under the mistaken impression that NAT is some kind of
> firewall all by itself. The goal of NAT is to make things *work* not
> to make things not work. If a NAT device can pass the ping, it will
> and should, unless configured not to.
It should only pass packets that match NAT table entries, which are
created when you send outgoing packets. So it should only pass ping
replies in response to ping requests to that IP.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
David Schwartz
> It should only pass packets that match NAT table entries, which are
> created when you send outgoing packets. So it should only pass ping
> replies in response to ping requests to that IP.
We're not talking about passing ping replies. We're talking about
passing inbound pings. If the inbound ping matches a NAT table entry,
the NAT device should pass it. (Again, unless it's specifically
configured as a firewall.)
And, of course, it may also pass them into devices configured into a
DMZ.
DS
Barry Margolin
<237b0d1c-3675-4af5...@x25g2000prf.googlegroups.com>,
David Schwartz <dav...@webmaster.com> wrote:
> On Nov 11, 6:07�am, Barry Margolin <bar...@alum.mit.edu> wrote:
>
> > It should only pass packets that match NAT table entries, which are
> > created when you send outgoing packets. �So it should only pass ping
> > replies in response to ping requests to that IP.
>
> We're not talking about passing ping replies. We're talking about
I know.
> passing inbound pings. If the inbound ping matches a NAT table entry,
> the NAT device should pass it. (Again, unless it's specifically
> configured as a firewall.)
But since NAT table entries get created as a result of outgoing packets,
how could it match one?
Maybe you meant to say port forwarding entry. On my Linksys router,
port forwarding can only be configured for TCP and UDP; you need a
protocol with ports. I expect this is typical of home routers.
Or maybe you're thinking of static NAT, which you can configure on
enterprise routers like Cisco and Juniper. This is essentially what
home routers call port forwarding, although they are more elaborate: you
can have multiple outside addresses and forward based on which outside
address was used; you can use an access list to determine which NAT
entry matches based on a number of criteria (which would allow you to
forward ICMP packets).
> And, of course, it may also pass them into devices configured into a
> DMZ.
Of course. But he already said he didn't have a DMZ configured.
David Schwartz
> > passing inbound pings. If the inbound ping matches a NAT table entry,
> > the NAT device should pass it. (Again, unless it's specifically
> > configured as a firewall.)
> But since NAT table entries get created as a result of outgoing packets,
> how could it match one?
An outgoing packet could have created the NAT entry.
> Maybe you meant to say port forwarding entry. On my Linksys router,
> port forwarding can only be configured for TCP and UDP; you need a
> protocol with ports. I expect this is typical of home routers.
The router might fail to forward the packet because it can't figure
out where to forward it. But if it can figure out where to forward it,
by any mechanism, then it will and should forward it, unless
configured not to.
> Or maybe you're thinking of static NAT, which you can configure on
> enterprise routers like Cisco and Juniper. This is essentially what
> home routers call port forwarding, although they are more elaborate: you
> can have multiple outside addresses and forward based on which outside
> address was used; you can use an access list to determine which NAT
> entry matches based on a number of criteria (which would allow you to
> forward ICMP packets).
That's certainly one way the router might know where the forward the
packet.
> > And, of course, it may also pass them into devices configured into a
> > DMZ.
> Of course. But he already said he didn't have a DMZ configured.
The point is that there is no specific reason the packets shouldn't
get through, except that one would typically expect the router would
be unable to forward them. However, if it is able to forward them, it
will and should, unless it's configured not to.
The OP seems to think that NAT is automatically a firewall, evidenced
by him describing his NAT device as a firewall, despite the fact that
there's no evidence it's been configured to firewall anything at all.
NAT might accidentally act as a firewall simply because the device has
no way to figure out where to forward the packet. But if it ever can
figure out how to forward it, it will and should.
There is no guarantee it won't be able to figure out how and where to
forward it.
DS
Barry Margolin
<94745534-49c6-4a26...@b36g2000prf.googlegroups.com>,
David Schwartz <dav...@webmaster.com> wrote:
> On Nov 11, 4:36�pm, Barry Margolin <bar...@alum.mit.edu> wrote:
>
> > > passing inbound pings. If the inbound ping matches a NAT table entry,
> > > the NAT device should pass it. (Again, unless it's specifically
> > > configured as a firewall.)
>
> > But since NAT table entries get created as a result of outgoing packets,
> > how could it match one?
>
> An outgoing packet could have created the NAT entry.
NAT entries are protocol- and port-specific. If you send an outgoing
ICMP Echo, a NAT entry will be created that allows incoming ICMP Echo
Reply. I don't think there's any kind of outgoing packet that would
create a NAT entry that allows incoming ICMP Echo.
> There is no guarantee it won't be able to figure out how and where to
> forward it.
Routers don't try to "figure out" this stuff. Outgoing packets open up
holes for very specific return traffic.
Although NAT routers aren't full-fledged firewalls, they are still very
good at blocking unsolicited incoming traffic.
Pascal Hambourg
Barry Margolin a ï¿œcrit :
>
> NAT entries are protocol- and port-specific.
How do you know the NAT behaviour of that specific device for sure ?
There is not even a clear unique definition of NAT. E.g. RFC 3489 (STUN)
describes four different types related to UDP traffic, not all are
port-specific.
David Schwartz
> > An outgoing packet could have created the NAT entry.
> NAT entries are protocol- and port-specific. If you send an outgoing
> ICMP Echo, a NAT entry will be created that allows incoming ICMP Echo
> Reply. I don't think there's any kind of outgoing packet that would
> create a NAT entry that allows incoming ICMP Echo.
You mean some devices create protocol and port-specific NAT entries if
they have to.
> > There is no guarantee it won't be able to figure out how and where to
> > forward it.
> Routers don't try to "figure out" this stuff. Outgoing packets open up
> holes for very specific return traffic.
Only because they have no choice.
> Although NAT routers aren't full-fledged firewalls, they are still very
> good at blocking unsolicited incoming traffic.
By pure accident, and only because they are unable to figure out where
to forward them. If a NAT device can figure out where to forward such
traffic, by any means, it should forward it unless specifically
configured not to.
This may be a case where his device was able to figure out where to
send the inbound traffic, and therefore did forward it because it
wasn't configured not to.
DS
Barry Margolin
<cf6f3076-9959-4d74...@d9g2000prh.googlegroups.com>,
David Schwartz <dav...@webmaster.com> wrote:
> On Nov 11, 10:39�pm, Barry Margolin <bar...@alum.mit.edu> wrote:
>
> > > An outgoing packet could have created the NAT entry.
>
> > NAT entries are protocol- and port-specific. �If you send an outgoing
> > ICMP Echo, a NAT entry will be created that allows incoming ICMP Echo
> > Reply. �I don't think there's any kind of outgoing packet that would
> > create a NAT entry that allows incoming ICMP Echo.
>
> You mean some devices create protocol and port-specific NAT entries if
> they have to.
If they don't, two inside devices trying to communicate concurrently
with the same outside server will not work. The NAT entries have to be
able to distinguish the connections, and send the return traffic to the
correct inside machine.
So unless your router is really crippled, NAT entries need to be similar
to TCBs, using a tuple of <protocol, localaddr, localport, remoteaddr,
remoteport> to match packets. ICMP error packets have to be processed
similarly to the way a network stack would: extract the IP/port info
from the embedded header, get the NAT entry for that connection, and
forward there (after appropriate NATting).
David Schwartz
> > You mean some devices create protocol and port-specific NAT entries if
> > they have to.
> If they don't, two inside devices trying to communicate concurrently
> with the same outside server will not work. The NAT entries have to be
> able to distinguish the connections, and send the return traffic to the
> correct inside machine.
Yes, *if* there are two inside devices trying to communicate
concurrently with the same outside server, and *if* the NAT device
only has one outside address, and *if* ....
Yes, if they have to, they'll do this. But they don't always have to.
> So unless your router is really crippled, NAT entries need to be similar
> to TCBs, using a tuple of <protocol, localaddr, localport, remoteaddr,
> remoteport> to match packets. ICMP error packets have to be processed
> similarly to the way a network stack would: extract the IP/port info
> from the embedded header, get the NAT entry for that connection, and
> forward there (after appropriate NATting).
While you will generally have to keep full information in order to
sensibly handle overload cases, you do not always have to subject an
inbound packet to a full match. (Obviously, you do it when you have to
do it.)
For example, if you receive an inbound packet and there is only one
NAT entry that matches the source and destination IP addresses of the
packet, you could forward to the inside host that NAT entry was for,
whether or not it matched the other port and protocol details.
(Assuming the device isn't specifically configured not to do that.)
This will break nothing and will make any number of things 'just
work'. The whole point of NAT is to make as many things as possible
'just work'. So NAT devices should do this.
DS