I'm running CentOS-6 on an HP MicroServer with a Billion 5200S modem/router connecting to the internet. I'm running the standard CentOS-6 firewall on the server.
(1) I can open port 22 on the Billion, allowing me to ssh in from outside. But for some reason I cannot ping the same address from outside. (I can ping it internally.) Why is this? I'm not sure if the problem lies with the router or the server? There does not seem to be any explicit rule on either to allow ICMP packets through.
(2) I have a Linksys WRT54GL WiFi router attached to the server, to allow access to the internet from laptops. This works fine. But I was surprised to find that when I turn OFF the firewall on the server this stops access to the internet on laptops. (I didn't test to see if re-booting the laptop would solve this.) Can disabling the firewall actually prevent some linkage?
Timothy Murphy wrote:
I'm running CentOS-6 on an HP MicroServer with a Billion 5200S modem/router connecting to the internet. I'm running the standard CentOS-6 firewall on the server.
(1) I can open port 22 on the Billion, allowing me to ssh in from outside. But for some reason I cannot ping the same address from outside. (I can ping it internally.) Why is this? I'm not sure if the problem lies with the router or the server? There does not seem to be any explicit rule on either to allow ICMP packets through.
This is due to modem refuses to answer to pings. You might have option to allow it in modem config.
Ping (ICMP) does not use ports but it is packet of type 8.
(2) I have a Linksys WRT54GL WiFi router attached to the server, to allow access to the internet from laptops. This works fine. But I was surprised to find that when I turn OFF the firewall on the server this stops access to the internet on laptops. (I didn't test to see if re-booting the laptop would solve this.) Can disabling the firewall actually prevent some linkage?
When you turn off firewall, it stops routing packets so they can not be passed to systems behind it.
Only option I can think of is to use shorewall as firewall and add NAT/Masquerade and the rest of the rules to routestoped confgi file:
"By default, when the Shorewall firewall is stopped it will deny access from all hosts. This page allows you to define hosts or networks that will still be accessible. No addresses to be accessible when stopped have been defined yet."
I am not sure if this does what you need, but if you need to turn down firewall a lot then consider this option.
Other then that, all you can do is to manually remove and add iptables rules without shuting down firewall.
On Tuesday 19 July 2011 09:11, the following was written:
Timothy Murphy wrote:
I'm running CentOS-6 on an HP MicroServer with a Billion 5200S modem/router connecting to the internet. I'm running the standard CentOS-6 firewall on the server.
(1) I can open port 22 on the Billion, allowing me to ssh in from outside. But for some reason I cannot ping the same address from outside. (I can ping it internally.) Why is this? I'm not sure if the problem lies with the router or the server? There does not seem to be any explicit rule on either to allow ICMP packets through.
This is due to modem refuses to answer to pings. You might have option to allow it in modem config.
Modems cannot answer pings. They are a bridge. The most likely reason why the OP cannot ping is because the firewall is not allowing it. Adding rules to allow pings should clear up this issue.
(2) I have a Linksys WRT54GL WiFi router attached to the server, to allow access to the internet from laptops. This works fine. But I was surprised to find that when I turn OFF the firewall on the server this stops access to the internet on laptops. (I didn't test to see if re-booting the laptop would solve this.) Can disabling the firewall actually prevent some linkage?
When you turn off firewall, it stops routing packets so they can not be passed to systems behind it.
IPTABLES does not route packets. IPTABLES manipulate packet so that they can be routed to the proper destination.
The reason the OP could not connect to the internet is because the firewall was NAT'ing his packets that were leaving his network to his internet facing ip address. Ounce the natting stopped the packets were sent to the internet with the address of his laptop which was most likely a private address. Since private addresses are not supposed to be routed on the internet the receiving router dropped the return packet.
Only option I can think of is to use shorewall as firewall and add NAT/Masquerade and the rest of the rules to routestoped confgi file:
The OP can continue to use IPTABLES the rules just need to be setup properly. No need to install other software when what you have installed will do the job.
OP can start by reading this Tutorial.
http://www.zoominternet.net/~lazydog/iptables-tutorial
Robert Spangler wrote:
On Tuesday 19 July 2011 09:11, the following was written:
Timothy Murphy wrote:
I'm running CentOS-6 on an HP MicroServer with a Billion 5200S modem/router connecting to the internet. I'm running the standard CentOS-6 firewall on the server.
(1) I can open port 22 on the Billion, allowing me to ssh in from outside. But for some reason I cannot ping the same address from outside. (I can ping it internally.) Why is this? I'm not sure if the problem lies with the router or the server? There does not seem to be any explicit rule on either to allow ICMP packets through.
This is due to modem refuses to answer to pings. You might have option to allow it in modem config.
Modems cannot answer pings. They are a bridge. The most likely reason why the OP cannot ping is because the firewall is not allowing it. Adding rules to allow pings should clear up this issue.
Please first read OP mail then give me lessons. HE said it was modem/router, I shortened it. I was little lazy.
How do you think he opened and forwarded port on his modem(/router) if he was in bridged mode?
(2) I have a Linksys WRT54GL WiFi router attached to the server, to allow access to the internet from laptops. This works fine. But I was surprised to find that when I turn OFF the firewall on the server this stops access to the internet on laptops. (I didn't test to see if re-booting the laptop would solve this.) Can disabling the firewall actually prevent some linkage?
When you turn off firewall, it stops routing packets so they can not be passed to systems behind it.
IPTABLES does not route packets. IPTABLES manipulate packet so that they can be routed to the proper destination.
You can nitpick if you like, but do not forget that OP is most probably noob (no disrespect intended). Why is necessary to write "War & Peace" when the result is the same, no firewall = no internet for PC's behind the CentOS system.
And lets finish it with a style: Timothy, you could turn off firewall and still have internet if you set static route in modem/router for the subnet used between CentOS and Clients, so modem/router does final NAT'ing.
The reason the OP could not connect to the internet is because the firewall was NAT'ing his packets that were leaving his network to his internet facing ip address. Ounce the natting stopped the packets were sent to the internet with the address of his laptop which was most likely a private address. Since private addresses are not supposed to be routed on the internet the receiving router dropped the return packet.
Irrelevant, modem/router is used.
I have spent last 6 years doing NAT-ing, policy routing, static and dynamic routing, complex iptables rules, marking packets to block and/or slowdown torrents but leave gamers alone, what ever you can think of. But there is not need to complicate things when the question is so simple:
"In the current state of his network, if he turns of firewall, clients behind it will not have internet."
Ljubomir Ljubojevic wrote:
(1) I can open port 22 on the Billion, allowing me to ssh in from outside. But for some reason I cannot ping the same address from outside.
This is due to modem refuses to answer to pings. You might have option to allow it in modem config.
Ping (ICMP) does not use ports but it is packet of type 8.
Thanks again for your response. Could CentOS be preventing me from pinging the system?
When you turn off firewall, it stops routing packets so they can not be passed to systems behind it.
Only option I can think of is to use shorewall as firewall and add NAT/Masquerade and the rest of the rules to routestoped confgi file:
I was using Shorewall before I went over to CentOS-6, and will probably go over to it.
But I don't really need to disable the firewall on the server. I just thought I'd try it as an experiment.
Timothy Murphy wrote:
Ljubomir Ljubojevic wrote:
(1) I can open port 22 on the Billion, allowing me to ssh in from outside. But for some reason I cannot ping the same address from outside.
This is due to modem refuses to answer to pings. You might have option to allow it in modem config.
Ping (ICMP) does not use ports but it is packet of type 8.
Thanks again for your response. Could CentOS be preventing me from pinging the system?
Further to my question, how can I determine if it is the Billion 5200S modem/router that is preventing pings, or if it is the CentOS-6 MicroServer attached to the modem/router?
I don't see any reference to ICMP on the modem web-page.
On the other hand the CentOS firewall seems to allow ICMP unless explicitly rejected (which I haven't done).
Surely it would be slightly odd for a modem/router to reject pings by default?
Is there any simple way, short of using something like ethereal, of determining if ICMP packets are reaching the computer, and being rejected there?
Timothy Murphy wrote:
Further to my question, how can I determine if it is the Billion 5200S modem/router that is preventing pings, or if it is the CentOS-6 MicroServer attached to the modem/router?
I don't see any reference to ICMP on the modem web-page.
On the other hand the CentOS firewall seems to allow ICMP unless explicitly rejected (which I haven't done).
Surely it would be slightly odd for a modem/router to reject pings by default?
Is there any simple way, short of using something like ethereal, of determining if ICMP packets are reaching the computer, and being rejected there?
ICMP packets are blocked by Billion, it's 99% chance, since public IP resides on the Billion. Only way (known to me) to pass ICMP to your CentOS server (on cheap modem/routers) is to do 1:1 NAT (all connections to all ports are redirected to system behind it with set IP).
If you need to be able to ping CemtOS system and not Billion, then you should set modem to bridge mode and pass public IP to CentOS. But caveat is that this would mean that if you turn on CentOS firewall or set it improperly you would be wide open, and that you will not be able to willfully bypass CentOS server (if he is down) and just plug PC's to modem directly.
Always Learning wrote:
On Wed, 2011-07-20 at 14:21 +0200, Ljubomir Ljubojevic wrote:
Ljubomir Ljubojevic (Love is in the Air)
Congratulations.
Are you planning to invite us to the wedding :-)
Hehehehe, no.
My first name (Ljubomir) is old Slavic name that means "He who loves peace", or "peace lover". Based on that and my skills in IT, I was given nickname Dr.Love by a customer, now long time friend. It spread around and I grew to love it. And since my skill set expanded because of the wireless ("in the air"), and I am a disco generation, I borrowed a song name from John Paul Young as a signature for StarOS forums, and then LQ and now mailing lists.. It fits like a glove.
Ljubomir Ljubojevic wrote:
ICMP packets are blocked by Billion, it's 99% chance, since public IP resides on the Billion. Only way (known to me) to pass ICMP to your CentOS server (on cheap modem/routers) is to do 1:1 NAT (all connections to all ports are redirected to system behind it with set IP).
If you need to be able to ping CemtOS system and not Billion, then you should set modem to bridge mode and pass public IP to CentOS. But caveat is that this would mean that if you turn on CentOS firewall or set it improperly you would be wide open, and that you will not be able to willfully bypass CentOS server (if he is down) and just plug PC's to modem directly.
Thanks for the response. I don't really mind if external sites cannot ping the machine; I was just a little surprised at this, particularly as I didn't see anything about it in the documentation.
I'll try asking on the Billion site.
On 20.7.2011 12:51, Timothy Murphy wrote:
Further to my question, how can I determine if it is the Billion 5200S modem/router that is preventing pings, or if it is the CentOS-6 MicroServer attached to the modem/router?
...
Is there any simple way, short of using something like ethereal, of determining if ICMP packets are reaching the computer, and being rejected there?
I would use tcpdump on the CentOS Server to be sure the icmp echo requests are arriving or not. tcpdump is something like ethereal but it could be as easy as
$ tcpdump -l proto \icmp or $ tcpdump -l proto \icmp and host sourceip or $ tcpdump -li ethX proto \icmp or ...
Markus Falb wrote:
I would use tcpdump on the CentOS Server to be sure the icmp echo requests are arriving or not. tcpdump is something like ethereal but it could be as easy as
$ tcpdump -l proto \icmp or $ tcpdump -l proto \icmp and host sourceip or $ tcpdump -li ethX proto \icmp or ...
Thanks for the instructions. Nothing seems to get through: -------------------------------------- [tim@helen ~]$ ping anghiari.homelinux.com PING anghiari.homelinux.com (79.46.6.203) 56(84) bytes of data.
--- anghiari.homelinux.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2000ms --------------------------------------
-------------------------------------- [root@alfred tim]# tcpdump -l proto \icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
--------------------------------------
So I assume the modem is rejecting the ICMP packets. As I said, I don't see anything about this in the modem documentation or on the modem web-site.
Timothy Murphy wrote:
Markus Falb wrote:
I would use tcpdump on the CentOS Server to be sure the icmp echo requests are arriving or not. tcpdump is something like ethereal but it could be as easy as
$ tcpdump -l proto \icmp or $ tcpdump -l proto \icmp and host sourceip or $ tcpdump -li ethX proto \icmp or ...
Thanks for the instructions. Nothing seems to get through:
[tim@helen ~]$ ping anghiari.homelinux.com PING anghiari.homelinux.com (79.46.6.203) 56(84) bytes of data.
--- anghiari.homelinux.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2000ms
[root@alfred tim]# tcpdump -l proto \icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
So I assume the modem is rejecting the ICMP packets. As I said, I don't see anything about this in the modem documentation or on the modem web-site.
ICMP packet always reaches the system with destination IP, unless it was purposely redirected by the system with the IP. In your case this is modem/router, so he responds.
Timothy Murphy wrote:
So I assume the modem is rejecting the ICMP packets. As I said, I don't see anything about this in the modem documentation or on the modem web-site.
I suppose another possibility is that some site along the way rejects ICMP packets?
traceroute seems to timeout in Milan: ----------------------------------- [root@helen tim]# traceroute anghiari.homelinux.com traceroute to anghiari.homelinux.com (79.46.6.203), 30 hops max, 40 byte packets 1 netopia (192.168.1.254) 0.951 ms 1.132 ms 1.389 ms 2 isp (159.134.155.19) 37.238 ms 39.560 ms 42.027 ms ... 12 telecomitalia.par02.atlas.cogentco.com (130.117.14.82) 67.140 ms telecomitalia.par02.atlas.cogentco.com (130.117.15.138) 92.952 ms ibs- resid.milano50.mil.seabone.net (93.186.128.246) 87.098 ms 13 * * * ... 30 * * * ----------------------------------- tcptraceroute gets to the modem, but after some timeouts: ----------------------------------- [root@helen tim]# tcptraceroute anghiari.homelinux.com traceroute to anghiari.homelinux.com (79.46.6.203), 30 hops max, 40 byte packets 1 netopia (192.168.1.254) 1.491 ms 1.534 ms 1.784 ms 2 isp (159.134.155.19) 36.195 ms 38.794 ms 41.328 ms ... 12 ibs-resid.milano50.mil.seabone.net (93.186.128.246) 85.084 ms 84.599 ms 86.881 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 host203-6-dynamic.46-79-r.retail.telecomitalia.it (79.46.6.203) 115.381 ms 107.416 ms 114.875 ms -----------------------------------
If anyone can interpret these for me, I shall be grateful.
Timothy Murphy wrote:
Timothy Murphy wrote:
So I assume the modem is rejecting the ICMP packets. As I said, I don't see anything about this in the modem documentation or on the modem web-site.
I suppose another possibility is that some site along the way rejects ICMP packets?
traceroute seems to timeout in Milan:
[root@helen tim]# traceroute anghiari.homelinux.com traceroute to anghiari.homelinux.com (79.46.6.203), 30 hops max, 40 byte packets 1 netopia (192.168.1.254) 0.951 ms 1.132 ms 1.389 ms 2 isp (159.134.155.19) 37.238 ms 39.560 ms 42.027 ms ... 12 telecomitalia.par02.atlas.cogentco.com (130.117.14.82) 67.140 ms telecomitalia.par02.atlas.cogentco.com (130.117.15.138) 92.952 ms ibs- resid.milano50.mil.seabone.net (93.186.128.246) 87.098 ms 13 * * * ... 30 * * *
tcptraceroute gets to the modem, but after some timeouts:
[root@helen tim]# tcptraceroute anghiari.homelinux.com traceroute to anghiari.homelinux.com (79.46.6.203), 30 hops max, 40 byte packets 1 netopia (192.168.1.254) 1.491 ms 1.534 ms 1.784 ms 2 isp (159.134.155.19) 36.195 ms 38.794 ms 41.328 ms ... 12 ibs-resid.milano50.mil.seabone.net (93.186.128.246) 85.084 ms 84.599 ms 86.881 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 host203-6-dynamic.46-79-r.retail.telecomitalia.it (79.46.6.203) 115.381 ms 107.416 ms 114.875 ms
If anyone can interpret these for me, I shall be grateful.
Those timeouts are normal occurrence. Some/most heavily loaded routers are configured to ignore traceroute requests, possibly even ICMP except for certain whitelisted IP's but cant remember of the top of my head.
Blocking ICMP's for customer IP's is not something ISP's do, for various reasons.
I take a look at Billion manual. It seams that you have to use it's firewall to add an allow rule for protocol icmp? and source IP 0.0.0.0. Destination might be also 0.0.0.0, haven't had the time to study it. This should allow pings from outside.
Ljubomir Ljubojevic wrote:
I take a look at Billion manual. It seams that you have to use it's firewall to add an allow rule for protocol icmp? and source IP 0.0.0.0. Destination might be also 0.0.0.0, haven't had the time to study it. This should allow pings from outside.
Thanks very much. Actually protocol ICMP does not seem to be allowed in the Firewall on my Billion 5200S RC. But I see that this protocol is allowed in "Access Management". I just tried adding a rule with ICMP protocol, but it seemed to have a bad effect! (I was cut off from the outside world.) I'm sure this is the right way to go, anyway, so I'll continue my experiments.
Thanks again.
On 7/20/2011 5:51 AM, Timothy Murphy wrote:
Further to my question, how can I determine if it is the Billion 5200S modem/router that is preventing pings, or if it is the CentOS-6 MicroServer attached to the modem/router?
I don't see any reference to ICMP on the modem web-page.
On the other hand the CentOS firewall seems to allow ICMP unless explicitly rejected (which I haven't done).
Surely it would be slightly odd for a modem/router to reject pings by default?
Do you only have one public IP? This sort of router is generally configured to do one->many source nat for a private network behind it. For tcp and udp packets there are more specified fields (port/socket info) that can be used to map inbound packets to the right private target either with configured entries or the dynamically maintained NAT table. But there's no way to distinguish whether an inbound ping should be answered by the modem itself or passed through if you have specified a default 'dmz' target. GRE packets (as used in pptp or router tunnels) have a similar problem of not having documented info that can be used to track the source NAT when there are multiple active sessions, although some routers manage to do it using microsoft conventions in the packets.
Is there any simple way, short of using something like ethereal, of determining if ICMP packets are reaching the computer, and being rejected there?
A sniffer like tcpdump or wireshare is the simple way. However, note that these see packets before they hit the host's iptables firewall so even if you see packets arriving, they may not be reaching any applications.
-
Always Learning -
Les Mikesell -
Ljubomir Ljubojevic -
Markus Falb -
Robert Spangler -
Timothy Murphy