Dear all, I'm facing problems when trying to insert a custom made connection with conntrack-tools. I am running a VM with Ubuntu 14.04, kernel 3.19.0-33 and conntrack v1.4.1. My network setup is the following: Host-A: (lan0 @ 192.168.0.101) <---> (lan0 @ 192.168.0.1) Router (wan0 @ 198.18.0.10) <---> (wan0: 198.18.0.100) Host-B The Host-A uses the router's IP as default gateway i.e. 192.168.0.1. The Router has the ip_forwarding and MASQUERADE enabled for doing NAT, i.e. iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o wan0 -j MASQUERADE. Now, I am attempting to play around with the connections created by the NAT and insert some custom made entries into the NAT table. I have tried to create NAT entries that correspond to outgoing traffic from Host-A towards Host-B, for both TCP and UDP with the following commands: #conntrack --create --orig-src 192.168.0.101 --orig-dst 198.18.0.100 --reply-src 198.18.0.100 --reply-dst 198.18.0.10 --proto 17 --orig-port-src 2222 --orig-port-dst 1111 --reply-port-src 1111 --reply-port-dst 2222 --timeout 60 #conntrack --create --orig-src 192.168.0.101 --orig-dst 198.18.0.100 --reply-src 198.18.0.100 --reply-dst 198.18.0.10 --proto 6 --orig-port-src 2222 --orig-port-dst 1111 --reply-port-src 1111 --reply-port-dst 2222 --timeout 60 --state SYN_SENT Using "conntrack --event" we can display a real-time event log. After inserting the previous 2 flows the output is the following: [UPDATE] udp 17 60 src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 [UNREPLIED] src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 mark=0 [UPDATE] tcp 6 60 SYN_SENT src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 [UNREPLIED] src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 mark=0 The client in Host-A is running: nc -u -p 2222 198.18.0.100 1111 / nc -p 2222 198.18.0.100 1111 The server in Host-B is running: nc -u -l 1111 / nc -l 1111 Using Wireshark I can see how the packet leaves the interface wan0 of the router, however it isn't mangled as SNAT so the packet are forwarded with the private IP address of the Host-A. This happens for both TCP and UDP. After the T timeout the entries expire and they are deleted. It seems to me that the conntrack insertion works correctly, but for some reason the NAT mangling is not happening anywhere. I have tried adding with flows with different --status and --state values, to no avail. [DESTROY] udp 17 src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 [UNREPLIED] src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [DESTROY] tcp 6 src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 [UNREPLIED] src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 Of course, if I don't create any state manually everything works fine. The following can be seen from the conntrack events. 1. For the UDP connection [NEW] udp 17 30 src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 [UNREPLIED] src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [UPDATE] udp 17 30 src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [UPDATE] udp 17 180 src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [ASSURED] 2. For the TCP connection [NEW] tcp 6 120 SYN_SENT src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 [UNREPLIED] src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [UPDATE] tcp 6 60 SYN_RECV src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [ASSURED] [UPDATE] tcp 6 120 FIN_WAIT src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [ASSURED] [UPDATE] tcp 6 30 LAST_ACK src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [ASSURED] [UPDATE] tcp 6 120 TIME_WAIT src=192.168.0.101 dst=198.18.0.100 sport=2222 dport=1111 src=198.18.0.100 dst=198.18.0.10 sport=1111 dport=2222 [ASSURED] For helping me debug the situation I have enabled the trace in iptables as follows: iptables -t raw -A PREROUTING -j TRACE iptables -t raw -A OUTPUT -j TRACE For the working UDP and TCP connections I can see these 2 additional traces that otherwise I don't if I set the entries myself. It seems that this is indeed creating the forwarding entries in the NAT. TRACE: nat:PREROUTING:policy:1 IN=lan0 OUT= MAC=86:fd:78:53:64:91:52:29:24:5c:5d:f9:08:00 SRC=192.168.0.101 DST=198.18.0.100 LEN=30 TOS=0x00 PREC=0x00 TTL=64 ID=23351 DF PROTO=UDP SPT=2222 DPT=1111 TRACE: nat:POSTROUTING:rule:1 IN= OUT=wan0 SRC=192.168.0.101 DST=198.18.0.100 LEN=30 TOS=0x00 PREC=0x00 TTL=63 ID=23351 DF PROTO=UDP SPT=2222 DPT=1111 LEN=10 TRACE: nat:PREROUTING:policy:1 IN=lan0 OUT= MAC=86:fd:78:53:64:91:52:29:24:5c:5d:f9:08:00 SRC=192.168.0.101 DST=198.18.0.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=22564 DF PROTO=TCP SPT=2222 DPT=1111 SEQ=67482932 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0059ED100000000001030307) TRACE: nat:POSTROUTING:rule:1 IN= OUT=wan0 SRC=192.168.0.101 DST=198.18.0.100 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=22564 DF PROTO=TCP SPT=2222 DPT=1111 SEQ=67482932 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0059ED100000000001030307) Sorry for the lengthy email, I thought it was for the best to give all the facts that I could gather to explain the situation. I would appreciate very much any kind of help you could give me. I have hit this issue for a while now and cannot seem to get around it. My goal is to create very specific SNAT and DNAT entries as well as playing around with Application Layer Gateway for some protocols. Thanks a lot in advance! Jesús Llorente Santos Networking Technology Department of Communications and Networking Aalto University -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
