![]() Ip netns exec router sh -c 'echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper' # this one might be global on former kernels and might need to be executed without "ip netns exec router" Ip netns exec router sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward' Ip -n client route add default via 2.2.2.2 Ip -n client addr add dev eth0 2.2.2.1/24 Ip -n router addr add dev client0 2.2.2.2/24 Ip -n router addr add dev tftp0 1.1.1.2/24 ![]() Ip -n client link add eth0 type veth peer netns router name client0 Ip -n tftp link add eth0 type veth peer netns router name tftp0 ![]() Using these commands to initialize the namespaces: ip netns del tftp || : Let's suppose it returned nothing or returned only nf_conntrack_tftp from previous rules usage, but not nf_nat_tftp (just rmmod nf_nat_tftp if present, to follow the line of thoughts below). Needed: root user, ip netns, atftpd and atftp (or equivalent server and client software).įrom scratch there's no reason to have a TFTP helper loaded on the router (so here on the testing host). If my guess is right, then TL DR, on router do this: modprobe nf_nat_tftpĮither the previous jessie kernel (3.16) auto-loaded nf_nat_tftp, either a script did it, but it appears it's not the case anymore.Īnyway, if that didn't help, here's how to easily reproduce the setup in OP's question, allowing to do any kind of test easily on any Linux system (but remember it's only virtualizing network here, nothing else). Can anyone hlep me figure out if I'm doing something wrong? Is the issue with the TFTP helper? Why would its behaviour have changed from Debian 8/Jessie? I did this same setup on several Debian 8/Jessie setups about a year ago and the TFTP helper worked as expected and I never had any issues. I won't clutter this post anymore if I can avoid it, but what's shown by tcpdump udp and host 1.1.1.1 confirms exactly what iptables and conntrack are showing me. But, as you'll see, the connection is only routed back to the client if the source port from the server is port 69 (regular old NAT)! Why is this? This is not the correct behaviour as far as I can tell. As you can also see, the expectation created in the EXPECT table has source port 0, which I assume means "any port". Pkts bytes target prot opt in out source destinationĥ9 2504 CT udp - * * 0.0.0.0/0 0.0.0.0/0 udp dpt:69 CT helper tftpĬhain OUTPUT (policy ACCEPT 280K packets, 36M bytes)Ĭhain POSTROUTING (policy ACCEPT 398 packets, 40794 bytes)ĥ678 349K MASQUERADE all - * enp1s0 0.0.0.0/0 0.0.0.0/0 All tables have default ACCEPT policy: = RAW Table =Ĭhain PREROUTING (policy ACCEPT 464K packets, 432M bytes) Iptables on the router has the following rules. The result is the that the router NATs the connection from the client to the server, sets up a translation rule for the return connection and happily waits for a return packet from the server with source port=69 that never arrives. According to RFC1350, the server is supposed to choose a random source port for its communication and direct it to the port that the client used as a source port originally (whew.). So only the regular MASQUERADE connection tracking is being used even though the conntrack table shows the expected return connection. The trouble I'm having is that the TFTP helper sets up an expectation for the return tftp connection (as expected) but, despite this, only traffic from port 69 on the TFTP server is getting translated and sent back to the client. I have configured iptables to use the Netfilter TFTP helper for tftp connections going to the TFTP server. The router is running iptables and is set to masquerade connections from the client's network to the server's network. They are connected via a router( Machine 'R'). ![]() I have a TFTP server (Machine 'S') and a TFTP client (Machine 'C') on different subnets.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |