I have been looking at a similar problem without success, at least so far. But I believe part of the problem is the connections you have created are never recognized as having anything to do with the traffic that follows. I have been looking at 'expectation's which allow creating entries that match later traffic and when they do they become regular connections. I am doing this in some experiments to understand application level gateways. For the 'expectation' and the ALG there needs to be kernel modules that do the IP translation of the following traffic, the modules are 'helpers'. You can see examples for FTP and TFTP in the kernel modules sources and docs. Have a look at the hacking document, especially the section on tracking/nat: http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-4.html#ss4.4 For a complete example the TFTP modules are pretty small: http://lxr.free-electrons.com/source/net/netfilter/ http://lxr.free-electrons.com/source/net/netfilter/nf_conntrack_tftp.c http://lxr.free-electrons.com/source/net/netfilter/nf_nat_tftp.c Anyhow, what I am trying to do is reverse NAT traversal, ie a machine on the WAN connects to the NAT with a DNS name inside, and the NAT uses connection tracking and DNS to make entries so it can connect inside, but the traffic will look like it is coming/going to the NAT and the outside machine, with the NAT translating, so the internal IP is not on the WAN. (ie a DNS/ALG). Having said all that I could be wrong as I don't have it working and thus lack evidence for my understanding. Hopefully I can get parts of it working. If you make progress let me know, as I sure would like a better understanding and perhaps a simpler solution that I am trying. Bill On Tuesday 09 February 2016 13:07, Llorente Santos Jesus wrote: > 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 -- 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
