I have this iptables rules:
# iptables -n -L -v --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 7392 4841K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
2 250K 531M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 0 0 ACCEPT all -- * * 192.168.0.0/24 0.0.0.0/0
4 0 0 ACCEPT all -- * * 80.1.1.69 0.0.0.0/0
5 6929 360K ACCEPT all -- * * 110.50.200.145 0.0.0.0/0
6 23 1404 ACCEPT all -- * * 100.40.30.0/24 0.0.0.0/0
7 781 46428 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW,ESTABLISHED
8 101 5928 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 state NEW,ESTABLISHED
9 5664 338K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
10 846 65748 LOGGING all -- * * 0.0.0.0/0 0.0.0.0/0
11 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 147K packets, 381M bytes)
num pkts bytes target prot opt in out source destination
Chain LOGGING (1 references)
num pkts bytes target prot opt in out source destination
1 734 46882 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 6/min burst 5 LOG flags 0 level 7 prefix `iptables: '
2 846 65748 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
The thing is the log file shows lines like these:
Jan 28 17:31:30 myhostname kernel: iptables: IN=eth0 OUT= MAC=78:24:ff:3a:3b:0e:00:09:0f:09:3b:06:08:00 SRC=188.85.58.233 DST=210.6.60.254 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=40229 DF PROTO=TCP SPT=56131 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Jan 21 22:54:03 myhostname kernel: iptables: IN=eth0 OUT= MAC=78:24:af:3a:3b:0c:00:09:0f:09:3b:06:08:00 SRC=217.12.26.61 DST=210.6.60.254 LEN=40 TOS=0x00 PREC=0x00 TTL=41 ID=0 DF PROTO=TCP SPT=35401 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
Note that, I have port 80 and 25 open.
Why some connection get block by iptables on 80 and 25?. I steel get trafic to those two services, but I dont understand why ip tables block some of the conections.
Thank you
You will note at the end of those log lines, the packets have the tcp reset flag set:
...WINDOW=0 RES=0x00RSTURGP=0
Probably, conntrack thinks that the connection is not in a state where this is a sensible packet to receive, and conntrack will mark them as INVALID. This means that they are not picked up by rule #2. They also do not count as NEW or ESTABLISHED when your rules #7-9 in your chain are hit.
Hence, they hit your log rule #10 and are rejected by rule #11.
You can either ignore this, or add a rule somewhere before your log line to deal with INVALID packets:
-m conntrack --ctstate INVALID -j DROP
Related
I would like to use a Raspberry Pi with an attached LTE Hat as an IoT device.
Currently I have managed to use ppp to get the LTE modem working. I've got IPv4 and IPv6 addresses and it is possible to ping from the device and to send data to an MQTT broker. At the end it would be fine to be able to log into the device using ssh. But currently I have trouble to ping the device or to get a working ssh connection to it over ppp.
I assume that something with the routing might be wrong. For this reason I post the current routing table of the IPv6:
route -6n
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: U 256 2 0 lo
2003:f5:cf00:1700::/64 :: U 202 3 0 eth0
2a02:3037:414:b1d4::/64 :: UA 256 1 0 ppp0
fe80::de6:3cd1:5bc0:1436/128 :: U 256 1 0 ppp0
fe80::xxxx:xxxx:xxxx:beb8/128 :: U 256 1 0 ppp0
fe80::/64 :: U 256 1 0 eth0
::/0 fe80::464e:6dff:fe5d:e7fc UG 202 2 0 eth0
::/0 fe80::de6:3cd1:5bc0:1436 UGDAe 1024 1 0 ppp0
::1/128 :: Un 0 6 0 lo
2003:f5:cf00:1700:xxxx:xxxx:xxxx:a761/128 :: Un 0 3 0 eth0
2003:f5:cf00:1700:xxxx:xxxx:xxxx:549f/128 :: Un 0 5 0 eth0
2a02:3037:414:b1d4:xxxx:xxxx:xxxx:beb8/128 :: Un 0 2 0 ppp0
fe80::xxxx:xxxx:xxxx:a761/128 :: Un 0 4 0 eth0
fe80::xxxx:xxxx:xxxx:beb8/128 :: Un 0 3 0 ppp0
ff00::/8 :: U 256 5 0 eth0
ff00::/8 :: U 256 3 0 ppp0
::/0 :: !n -1 1 0 lo
The following commands fail (if entered on a different device ...)
ping -6 2a02:3037:414:b1d4:xxxx:xxxx:xxxx:beb8
ssh 2a02:3037:414:b1d4:xxxx:xxxx:xxxx:beb8
Would be nice if someone could give me a hint.
Thanks
from 10.18.90.139 to 10.18.90.254, using normal icmp protocol with scapy via python gets no answer; but ping gets reply, what could be the reason
Tried to ping an IP via scapy
>>> ip = "10.18.90.254"
>>> from scapy.all import sr1, IP, ICMP
>>> sr1(IP(ip/ICMP()))
Begin emission:
.......Finished sending 1 packets.
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C
Received 1073 packets, got 0 answers, remaining 1 packets
Checked there is no proxy
[root# run]# env | grep -i pro
[root# run]# env | grep -i ht
But ping works fine
PING 10.18.90.254 (10.18.90.254) 56(84) bytes of data.
64 bytes from 10.18.90.254: icmp_seq=1 ttl=64 time=0.315 ms
64 bytes from 10.18.90.254: icmp_seq=2 ttl=64 time=0.264 ms
^C
--- 10.18.90.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1462ms
rtt min/avg/max/mdev = 0.264/0.289/0.315/0.030 ms
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
10.18.90.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4
10.9.67.0 0.0.0.0 255.255.255.0 U 0 0 0 eth5
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth5
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth4
135.0.0.0 10.9.67.1 255.0.0.0 UG 0 0 0 eth5
0.0.0.0 10.18.90.254 0.0.0.0 UG 0 0 0 eth4
Try using something like this:
sr1(IP(dst="10.18.90.254") / ICMP())
Pinging a system in the internet works:
root#553c9e5ce5ea:/# ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=9.61 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.619/9.619/9.619/0.000 ms
Pinging a system in the internal (corporate) network, does not work:
root#553c9e5ce5ea:/# ping -c 1 10.97.179.110
PING 10.97.179.110 (10.97.179.110) 56(84) bytes of data.
--- 10.97.179.110 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
The routing in the container is straightforward:
root#553c9e5ce5ea:/# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Pinging the same system from the docker host is working fine:
host » ping -c 1 10.97.179.110
PING 10.97.179.110 (10.97.179.110) 56(84) bytes of data.
64 bytes from 10.97.179.110: icmp_seq=1 ttl=60 time=4.70 ms
--- 10.97.179.110 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.703/4.703/4.703/0.000 ms
The system is reachable via a vpn interface in the docker host:
host » route -n | grep '^10\.'
10.0.0.0 0.0.0.0 255.248.0.0 U 0 0 0 tunsnx
10.8.0.0 0.0.0.0 255.252.0.0 U 0 0 0 tunsnx
10.12.0.0 0.0.0.0 255.254.0.0 U 0 0 0 tunsnx
10.14.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tunsnx
10.15.0.0 0.0.0.0 255.255.240.0 U 0 0 0 tunsnx
10.15.20.0 0.0.0.0 255.255.252.0 U 0 0 0 tunsnx
10.15.24.0 0.0.0.0 255.255.248.0 U 0 0 0 tunsnx
10.15.32.0 0.0.0.0 255.255.224.0 U 0 0 0 tunsnx
10.15.64.0 0.0.0.0 255.255.192.0 U 0 0 0 tunsnx
10.15.113.108 0.0.0.0 255.255.255.255 UH 0 0 0 tunsnx
10.15.128.0 0.0.0.0 255.255.128.0 U 0 0 0 tunsnx
10.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 tunsnx
10.32.0.0 0.0.0.0 255.224.0.0 U 0 0 0 tunsnx
10.64.0.0 0.0.0.0 255.192.0.0 U 0 0 0 tunsnx
10.128.0.0 0.0.0.0 255.128.0.0 U 0 0 0 tunsnx
Why is the host not properly routing the traffic coming from the docker container?
EDIT
I have been checking the IP tables counters, and this is what I see after ping -c 100 (a host on the VPN):
» sudo iptables -x -v --line-numbers -L FORWARD | head
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 100 8400 DOCKER-ISOLATION all -- any any anywhere anywhere
2 0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
3 0 0 DOCKER all -- any docker0 anywhere anywhere
4 100 8400 ACCEPT all -- docker0 !docker0 anywhere anywhere
5 0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
6 0 0 ACCEPT all -- any br-ad32be160e27 anywhere anywhere ctstate RELATED,ESTABLISHED
7 0 0 DOCKER all -- any br-ad32be160e27 anywhere anywhere
8 0 0 ACCEPT all -- br-ad32be160e27 !br-ad32be160e27 anywhere anywhere
Pinging a host on the internet (8.8.8.8) gives this:
» sudo iptables -x -v --line-numbers -L FORWARD | head
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 200 16800 DOCKER-ISOLATION all -- any any anywhere anywhere
2 100 8400 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
3 0 0 DOCKER all -- any docker0 anywhere anywhere
4 100 8400 ACCEPT all -- docker0 !docker0 anywhere anywhere
5 0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
6 0 0 ACCEPT all -- any br-ad32be160e27 anywhere anywhere ctstate RELATED,ESTABLISHED
7 0 0 DOCKER all -- any br-ad32be160e27 anywhere anywhere
8 0 0 ACCEPT all -- br-ad32be160e27 !br-ad32be160e27 anywhere anywhere
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have a simple network with three Linux systems running CentOS 2.6.
Linux 1 (eth1: 192.138.14.1)----- (eth4:192.138.14.4) Linux 2 (eth2: 192.138.4.3)------(eth3: 192.138.4.2) Linux 3
I am unable to ping Linux 3 from Linux 1. What I am able to ping though is from Linux 1 to Linux 2 (eth2) and from Linux 3 to Linux 2 (eth4). This means from Linux 1, I am able to ping 192.138.4.3 but not 192.138.4.2.
Following is the output of route -n command in Linux1
Linux1# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.138.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.138.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.135.18.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 0 eth3
0.0.0.0 10.135.18.1 0.0.0.0 UG 0 0 0 eth0
In Linux 2:
Linux2# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.138.15.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.138.14.0 192.138.14.4 255.255.255.0 UG 0 0 0 eth4
192.138.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4
192.138.4.0 192.138.4.3 255.255.255.0 UG 0 0 0 eth2
192.138.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
10.135.18.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.138.16.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1004 0 0 eth2
169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 0 eth3
169.254.0.0 0.0.0.0 255.255.0.0 U 1006 0 0 eth4
0.0.0.0 10.135.18.1 0.0.0.0 UG 0 0 0 eth0
In Linux 3:
Linux3# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.138.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
192.138.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
10.135.18.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1005 0 0 eth3
0.0.0.0 10.135.18.1 0.0.0.0 UG 0 0 0 eth0
I have enabled IP forwarding in Linux 2
Linux2# vi /etc/sysctl.conf
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
Linux2#: sysctl -p
sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_sack = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
The result of iptables -L in Linux 2:
Linux2# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
To ping Linux3 from Linux 1, should I be adding specific rules for icmp in iptables ? If not, What am I missing ?
I guess the problem is that you're not on the same network. When linux1 tries to send a packet to 192.138.4.2 it looks at the routing table and sees that it should go to eth1. But it also sees that there is no GW, so it assumes that the packet is on the same network. So it sends an arp request for 192.138.4.2 but receives no answer.
You can verify my assumption by running "tcpdump -i eth1 arp" on linux 1 and see that you send a request and see no response. You can also just type 'arp' and see that you have an incomplete entry.
So basically your routing table should include a GW where packets are intended to be routed.
For example, instead of
192.138.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
It should be something like
192.138.4.0 192.138.14.4 255.255.255.0 UG 0 0 0 eth1
And same on the other side.
I'm trying to use symmetric key when I sync the time and because it's for a product of my company, I can only use the command "ntpd", so no commands like "ntpq" for more information.
Here is what I've done:
1) sync time without authentication key, it works
2) then ntp-gen to generate MD5 key file at server side
/tmp/ntp.keys
2 MD5 N6\VRj&\t96tl]Xb#%$^ # MD5 key
3 MD5 M_4ga}||b_WM#te[\S33 # MD5 key
3) pick up one line and add to ntp.keys at client side
/tmp/ntp.keys
2 MD5 N6\VRj&\t96tl]Xb#%$^ # MD5 key
4) ntp.conf at server side
broadcast 10.66.208.26 key 2
keys /tmp/ntp.keys
trustedkey 2
requestkey 2
controlkey 2
5) ntp.conf at client side
server 10.66.208.122
6) command to syn time:
ntpd -a -k /tmp/ntp.keys -g -q -d -c /tmp/ntp.conf
because of the OS conception, we use only ** -a ** to active authentication check, without key number.
7) then the output:
the problem is at the end: no servers found. I cannot understand, since there is "transmit" and "receive"
ntpd 4.2.6p3#1.2290 Thu Sep 4 21:36:24 UTC 2014 (2)
5 Sep 16:10:42 ntpd[4958]: proto: precision = 3.875 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
5 Sep 16:10:42 ntpd[4958]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
5 Sep 16:10:42 ntpd[4958]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
5 Sep 16:10:42 ntpd[4958]: Listen and drop on 1 v6wildcard :: UDP 123
5 Sep 16:10:42 ntpd[4958]: Listen normally on 2 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
5 Sep 16:10:42 ntpd[4958]: Listen normally on 3 wan2 10.66.208.26 UDP 123
restrict: op 1 addr 10.66.208.26 mask 255.255.255.255 mflags 00003000 flags 0000001
5 Sep 16:10:42 ntpd[4958]: Listen normally on 4 iloc 192.168.0.1 UDP 123
restrict: op 1 addr 192.168.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
5 Sep 16:10:42 ntpd[4958]: Listen normally on 5 lo ::1 UDP 123
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
5 Sep 16:10:42 ntpd[4958]: Listen normally on 6 wan2 fe80::7e66:9dff:fe12:3fd UDP 123
restrict: op 1 addr fe80::7e66:9dff:fe12:3fd mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
5 Sep 16:10:42 ntpd[4958]: Listen normally on 7 iloc fe80::7e66:9dff:fe12:3ff UDP 123
restrict: op 1 addr fe80::7e66:9dff:fe12:3ff mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
5 Sep 16:10:42 ntpd[4958]: Listen normally on 8 plc0 fe80::1010:ff:fe00:0 UDP 123
restrict: op 1 addr fe80::1010:ff:fe00:0 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
5 Sep 16:10:42 ntpd[4958]: peers refreshed
5 Sep 16:10:42 ntpd[4958]: Listening on routing socket on fd #25 for interface updates
peer_clear: at 0 next 1 associd 53920 refid INIT
event at 0 10.66.208.122 8011 81 mobilize assoc 53920
newpeer: 10.66.208.26->10.66.208.122 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
event at 0 0.0.0.0 c011 01 freq_not_set
transmit: at 1 10.66.208.26->10.66.208.122 mode 3 len 48
receive: at 13 10.66.208.26<-10.66.208.122 mode 4 len 48
packet: flash header 1420
transmit: at 15 10.66.208.26->10.66.208.122 mode 3 len 48
receive: at 15 10.66.208.26<-10.66.208.122 mode 4 len 48
packet: flash header 1420
transmit: at 17 10.66.208.26->10.66.208.122 mode 3 len 48
receive: at 17 10.66.208.26<-10.66.208.122 mode 4 len 48
packet: flash header 1420
transmit: at 19 10.66.208.26->10.66.208.122 mode 3 len 48
receive: at 19 10.66.208.26<-10.66.208.122 mode 4 len 48
packet: flash header 1420
transmit: at 21 10.66.208.26->10.66.208.122 mode 3 len 48
receive: at 21 10.66.208.26<-10.66.208.122 mode 4 len 48
packet: flash header 1420
5 Sep 16:11:05 ntpd[4958]: ntpd: no servers found
ntpd: no servers found
I think your ntp.keys file might be off. Instead of MD5 for the key type, you want M.
/tmp/ntp.keys
2 M N6\VRj&\t96tl]Xb#%$^ # MD5 key
3 M M_4ga}||b_WM#te[\S33 # MD5 key
Check out ntp.org here.