Responses from kubernetes containers getting lost - docker

I have installed kubernetes on openstack. The setup has one master and one node on coreos.
I have a pod hosting an SIP application on UDP port 5060 and I have created service as NODEPORT on 5060.
The spec:
"spec": {
"ports": [
{
"port": 5061,
"protocol": "UDP",
"targetPort": 5060,
"nodeport": 5060,
"name": "sipu"
}
],
"selector": {
"app": "opensips"
},
"type": "NodePort"
}
IPs
Public IP of node: 192.168.144.29.
Private IP of node: 10.0.1.215..
IP of the container:10.244.2.4.
docker0 interface: 10.244.2.1.
Now, the problem.
I send a SIP request to the application and expect a 200 OK response, which I am not getting.
To trace the same, I installed TCPDUMP on the container and the node.
On the container, I can see the request and response packet captured while on the node itself I just see the request packet. Don't understand why the packet is getting lost.
Below is tcpdump of container:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
06:12:20.391171 IP (tos 0x0, ttl 64, id 13372, offset 0, flags [DF], proto UDP (17), length 1010)
10.244.2.1.50867 > 10.244.2.4.5060: [bad udp cksum 0x1ddc -> 0xe738!] SIP, length: 982
PUBLISH sip:service-1#opensipstest.org SIP/2.0
Via: SIP/2.0/UDP 192.168.144.10:5060;branch=z9hG4bK-5672-1-0
Max-Forwards: 20
From: service <sip:service-1#opensipstest.org>;tag=1
To: sut <sip:service-1#opensipstest.org>
Call-ID: 1-5672#192.168.144.10
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
Content-Length: 607
User-Agent: Sipp v1.1-TLS, version 20061124
<?xml version="1.0"?>
<deleted presence xml to reduce size>
06:12:20.401126 IP (tos 0x10, ttl 64, id 11888, offset 0, flags [DF], proto UDP (17), length 427)
10.244.2.4.5060 > 10.244.2.1.5060: [bad udp cksum 0x1b95 -> 0xeddc!] SIP, length: 399
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.144.10:5060;received=10.244.2.1;branch=z9hG4bK-5672-1-0
From: service <sip:service-1#opensipstest.org>;tag=1
To: sut <sip:service-1#opensipstest.org>;tag=332ff20b76febdd3c55f313f3efc6bb8-ca08
Call-ID: 1-5672#192.168.144.10
CSeq: 1 PUBLISH
Expires: 3600
SIP-ETag: a.1450478491.39.2.0
Server: OpenSIPS (1.8.4-notls (x86_64/linux))
Content-Length: 0
06:12:20.401364 IP (tos 0x0, ttl 64, id 13374, offset 0, flags [DF], proto UDP (17), length 427)
10.244.2.1.58836 > 10.244.2.4.5060: [bad udp cksum 0x1b95 -> 0x1bcc!] SIP, length: 399
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.144.10:5060;received=10.244.2.1;branch=z9hG4bK-5672-1-0
From: service <sip:service-1#opensipstest.org>;tag=1
To: sut <sip:service-1#opensipstest.org>;tag=332ff20b76febdd3c55f313f3efc6bb8-ca08
Call-ID: 1-5672#192.168.144.10
CSeq: 1 PUBLISH
Expires: 3600
SIP-ETag: a.1450478491.39.2.0
Server: OpenSIPS (1.8.4-notls (x86_64/linux))
Content-Length: 0
And tcpdump of node:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
06:12:20.390772 IP (tos 0x0, ttl 127, id 20196, offset 0, flags [none], proto UDP (17), length 1010)
192.168.144.10.5060 > 10.0.1.215.5060: [udp sum ok] SIP, length: 982
PUBLISH sip:service-1#opensipstest.org SIP/2.0
Via: SIP/2.0/UDP 192.168.144.10:5060;branch=z9hG4bK-5672-1-0
Max-Forwards: 20
From: service <sip:service-1#opensipstest.org>;tag=1
To: sut <sip:service-1#opensipstest.org>
Call-ID: 1-5672#192.168.144.10
CSeq: 1 PUBLISH
Expires: 3600
Event: presence
Content-Length: 607
User-Agent: Sipp v1.1-TLS, version 20061124
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" />
Nodeport rules from Iptable
Chain KUBE-NODEPORT-CONTAINER (1 references)
pkts bytes target prot opt in out source destination
12 8622 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/opensips:sipu */ udp dpt:5060 redir ports 40482
3 95 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-udp-service: */ udp dpt:6000 redir ports 47497
Chain KUBE-NODEPORT-HOST (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/opensips:sipu */ udp dpt:5060 to:10.0.1.215:40482
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-udp-service: */ udp dpt:6000 to:10.0.1.215:47497
I am happy to share more info if required. I have tried to dig in my capacity, but now I don't know what to look therefore requesting some help here.
EDIT
I did the same test on TCP. On TCP, it works as expected.
Thanks

5060 is outside the default Service Node Port Range:
http://kubernetes.github.io/docs/user-guide/services/#type-nodeport
Creation of the service should have failed.
You can try a different port, or create a cluster using a different range, by specifying --service-node-port-range on kube-apiserver.
https://github.com/kubernetes/kubernetes/blob/43792754d89feb80edd846ba3b40297f2a105e14/cmd/kube-apiserver/app/options/options.go#L232
You should also check whether the response can be seen from other nodes. There are issues with "hairpin mode" when communicating within the same node.
Also, when reporting problems, please specify the Kubernetes release.

Related

Dante SOCKS5 proxy server configuration for ipv6

Below is my dante configuration file
logoutput: /var/log/socks.log
internal: enp0s3 port = 1080
external: enp0s3
clientmethod: none
socksmethod: none
user.privileged: root
user.notprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect disconnect
}
client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect disconnect
}
socks block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
It works in ipv4 when ipv6 disabled, this how I disabled ipv6
vim /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.enp0s3.disable_ipv6 = 1
sysctl -p
But when ipv6 is enabled, its not returning expected result
This is how I test the connection
curl -x socks5://user:pass#192.168.1.11:1080 ifconfig.co
Result
curl: (7) Can't complete SOCKS5 connection to 2606:4700:3036::ac43:85e4:80. (6)

Unable to ping docker host but the world is reachable

I am able to ping rest of the world but not the host from container in which docker container is running. I am sure someone encountered this issue before
See below details
Ubuntu 14.04.2 LTS (GNU/Linux 3.16.0-30-generic x86_64
**Container is using "bridge" network
Docker version 18.06.1-ce, build e68fc7a**
IP address for eth0: 135.25.87.162
IP address for eth1: 192.168.122.55
IP address for eth2: 135.21.171.209
IP address for docker0: 172.17.42.1
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 135.21.248.1 0.0.0.0 UG 0 0 0 eth1
135.21.171.192 * 255.255.255.192 U 0 0 0 eth2
135.21.248.0 * 255.255.255.0 U 0 0 0 eth1
135.25.87.128 * 255.255.255.192 U 0 0 0 eth0
172.17.0.0 * 255.255.0.0 U 0 0 0 docker0
192.168.122.0 * 255.255.255.192 U 0 0 0 eth1
#ping commands from container
# ping google.com
PING google.com (64.233.177.113): 56 data bytes
64 bytes from 64.233.177.113: icmp_seq=0 ttl=29 time=51.827 ms
64 bytes from 64.233.177.113: icmp_seq=1 ttl=29 time=50.184 ms
64 bytes from 64.233.177.113: icmp_seq=2 ttl=29 time=50.991 ms
^C--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 50.184/51.001/51.827/0.671 ms
# ping 135.25.87.162
PING 135.25.87.162 (135.25.87.162): 56 data bytes
^C--- 135.25.87.162 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
root#9ed17e4c2ee3:/opt/app/tomcat#

docker port mapping not forwarding traffic

I try to use this container: https://hub.docker.com/r/tiredofit/freepbx/
For that i have created this compose file:
https://pastebin.com/CkL1y0jd
I have proxied port 80 to my internal IP 172.20.0.45. This works great. But Port 5160 is not reachable from the outside.
On my Docker host i have ran
ngrep -W byline -d eno1 port 5160
This gives me the following output:
U 192.168.30.22:54194 -> 192.168.50.20:5160
REGISTER sip:pbx.UsualyMyDomain.ch:5160;transport=UDP SIP/2.0.
Via: SIP/2.0/UDP 212.XX.XX.XXX:54194;branch=z9hG4bK-524287-1---9bb8a42e6116af86;rport.
Max-Forwards: 70.
Contact: <sip:120#212.XXX.XXX.XXX:54194;rinstance=c4ebbf8b0a8fd276;transport=UDP>.
To: "4141XXXXXXX"<sip:120#pbx.UsualyMyDomain.ch:5160;transport=UDP>.
From: "4141XXXXXXX"<sip:120#pbx.UsualyMyDomain.ch:5160;transport=UDP>;tag=b4afdd24.
Call-ID: uXyh0WASXl2Cpp3oD0RYtw...
CSeq: 2 REGISTER.
Expires: 60.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE.
User-Agent: Zoiper rv2.9.RC37-15-g9fc1f76ee4.
Allow-Events: presence, kpml, talk.
Content-Length: 0.
But if i run the above command inside of my container, then i get no packets at all:
ngrep -W byline -d eno1 port 5160
interface: eno1 (172.20.0.0/255.255.255.0)
filter: (ip or ip6) and ( port 5160 )
So where do i have to search for problems now?
netstats -tln
shows:
tcp6 0 0 :::5160 :::* LISTEN 13316/docker-proxy
But no UDP6 or UDP.
Could that be the problem?
Thanks in advance
Problem solved!
For all those out there who find a similar problem.
Read this: http://bhashitparikh.com/2016/02/03/when-port-forwarding-didnt-work-in-docker.html
One of the problems was that you must insert your Docker IP under SIP-CHAN Settings as bind address. Then also use static-ip and enter your docker ip.
And last but not least, add this to the compose file:
5160:5160/udp
5060:5060/udp
Otherwise it will only listen to tcp traffic!
now it works :)

Puma: Having issue with iptables port 3000

I'm having issue with iptables and puma(port 3000) using this config:
Chain INPUT (policy DROP 18 packets, 1982 bytes)
pkts bytes target prot opt in out source destination
14 1076 ACCEPT all -- eth0 any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:ssh state NEW,ESTABLISHED
0 0 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT tcp -- any any *.*.*.* anywhere
0 0 ACCEPT tcp -- any any *.*.*.* anywhere
0 0 ACCEPT tcp -- any any *.*.*.* anywhere
0 0 ACCEPT tcp -- any any *.*.*.* anywhere
13 6666 ACCEPT tcp -- any any *.*.*.* anywhere tcp dpt:3000 state NEW,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 31 packets, 2646 bytes)
pkts bytes target prot opt in out source destination
When I try to access port 3000 from authorize ip, no data is being return. But when I check using nmap if port 3000 is open. Did I misconfigured something in iptables? Thanks.

ICMP replies seen by tcpdump but ping 100% fails [closed]

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 virtual interface (oip1) configured which has a valid IP config. When I try to ping an address on the internet from oip1, I can see the ICMP echo requests/replies on tcpdump, but ping still reports 100% failing.
root#openair-PC:~/openair4G# ifconfig oip1
oip1 Link encap:AMPR NET/ROM HWaddr
inet addr:192.188.0.2 Bcast:192.188.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:840 (840.0 B) TX bytes:840 (840.0 B)
I've created a new table "lte":
root#openair-PC:~/openair4G# ip rule show
0: from all lookup local
32743: from all fwmark 0x1 lookup lte
32766: from all lookup main
32767: from all lookup default
Thus, I'm marking packets to/from oip1 address:
root#openair-PC:~/openair4G# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere 192.188.0.0/24 MARK set 0x1
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
MARK all -- 192.188.0.0/24 anywhere MARK set 0x1
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Then, I added a default gateway for table "lte":
root#openair-PC:~/openair4G# ip route show table lte
default dev oip1 scope link
ping result:
openair#openair-PC:~/openair4G/cmake_targets$ ping -c 5 -I oip1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.188.0.2 oip1: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
tcpdump screen:
openair#openair-PC:~/openair4G$ sudo tcpdump -p -i oip1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on oip1, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:19:10.576680 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 1, length 64
17:19:11.021851 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 1, length 64
17:19:11.576617 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 2, length 64
17:19:11.752243 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 2, length 64
17:19:12.576583 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 3, length 64
17:19:12.676980 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 3, length 64
17:19:13.576559 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 4, length 64
17:19:13.767922 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 4, length 64
17:19:14.576561 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 5, length 64
17:19:15.097164 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 5, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
As you can see, all packets can be seen by tcpdump.
Does anyone have an idea about this ?
Best regards,
I finally solved this. It was cause by rp_filter activated on the concerned interface and on all the system as well. I disabled it with: sysctl -w net.ipv4.conf.all.rp_filter=0 (replace all with the interface also).
This could have been caused by the reverse-path-filtering done by kernel. This is likely to occur if you are doing things like proxy-arp in the next hop. The system thinks that the packet received is a spoofed one (if the reverse-path-filtering is enabled) and drops it.
Obvious (but not suggested) way is to disable the reverse-path-filtering. Another way is to set the default gateway in the host for the pinged IP, through the intended interface.

Resources