RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs
Thanks Martin. My rp_filter was disabled on server box B: # cat /proc/sys/net/ipv4/conf/all/rp_filter 0 I got it to work however, along the lines you were suggesting like this: On Box A: iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 on box B, I finally found ACK packets. I do not know why I could not see them before. It turns out that box B was trying to route ACKs via its WAN interface eth0 directly to the client, in some sort of asymmetric router fashion. This did not work. So on B, I routed ACKs back to A: #ip rule add from $BOX_B_ETH1 lookup 3 #ip route add default via $BOX_A_ETH1 table 3 Now it works, with DNAT on A and without anything else. I have 1 small follow-up question: 1) when I add custom rules like #ip rule add from $BOX_B_ETH1 lookup 3 it does not take effect for at least 1 minute, perhaps 2-3. Why is that? This is confusing, since it makes one think that the rule does not work, while in reality it just has not taken effect. Thanks a lot for your help, Alec. -Original Message- From: Martin A. Brown [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 8:40 PM To: Alec Matusis Cc: lartc@mailman.ds9a.nl Subject: RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec, : I tried implementing DNAT as you indicated: : : iptables -t nat -i eth0 [...] -j DNAT --to-destination $BOX_B_ETH1 : : After that, I can see SYN packets arriving on BOX_B_ETH1, having : the original client's IP. OK, that means DNAT + routing on your BOX_A is working correctly. : Only half of the connection gets established after this: I cannot : see ACK packets from box B anywhere (neither on BOX_B_ETH0, nor : on BOX_A_ETH0). This is where your problem lies now. You need to find out why the SYN (which you said was transmitted to BOX_B_ETH1) is not getting accepted by this IP stack. * reverse path filtering (net.ipv4.conf.*.rp_filter) * packet filtering rules on BOX_B? : I think the reason is that since box A never sends a SYN packet : itself, it never classifies the connection as ESTABLISHED, so all : further traffic gets rejected. It's still a mystery to me what : happens to SYN packets from be in this scenario however. BOX_A will never have a socket in ESTABLISHED state. BOX_A will have a state entry in the /proc/net/ip_conntrack table. Examine /proc/net/ip_conntrack after sending a SYN to BOX_B. : It turns out that I have to supplement DNAT with SNAT for this to work : correctly. : On box A: : iptables -t nat -i eth0 -p tcp -m tcp --dport $SERVER_PORT -j DNAT : --to-destination $BOX_B_ETH1 : iptables -t nat -A POSTROUTING -d $BOX_B_ETH1 -p tcp -m tcp --dport : $SERVER_PORT -j SNAT --to-source $BOX_A_ETH1 If this works, then I think you problem may be reverse path filtering. : in this case, the clients can connect, however the server on B : sees only IP of BOX_A_ETH1, not the original client IPs. [ tproxy recommendation snipped ] - -Martin - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFF8OURHEoZD1iZ+YcRAoenAJ9XCZyMf4K7TVCTs28bzIGeu3EEewCg07Cw Spk8a+T/th+ESyPN4hSTjYs= =k+5E -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems getting multipath routes to balance
* Luciano Ruete Try a kernel without CONFIG_IP_ROUTE_MULTIPATH_CACHED I did and it worked. Thanks. I primarily wanted caching but oh well... there are several threads on this topic in the archive, one as reference: http://archives.free.net.ph/message/20060618.150532.8a6cc07f.en.html Looked but didn't find it of course... :-/ If it solves the problem, maybe is time to contact the author of Multipath Cached and send some report. I ended up asking on the netdev list, and got a reply there that cached ECMP is simply broken for forwarded packets. I submitted a patch to document it in the configuration screen, no idea if it will get merged though. -- Tore Anderson ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Mark on FTP passive traffic
Hi, I use for a customer a Linux router/firewall with 1 internal interface connected to the LAN and 3 external interfaces connected to 3 different ISP. I use a kernel 2.6.17 with a routes patch from Julian Anastasov. I mark outgoing FTP traffic for the routing. With the rules below I do not have a problem with the active/normal FTP to connect on FTP server. But the passive FTP does not pass because I do not know how to mark the related packets whose ports are negotiated in FTP session. I quote only the rules for the internal interface and one of the external interfaces. The rules are the same ones for the three external interfaces. # global rule for all traffic iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # FTP rule iptables -A FORWARD -i $INTERNAL_INTERFACE -o $EXTERNAL_INTERFACE1 -p tcp -s $INTERNAL_LAN --sport $UNPRIVPORTS --dport 21 -m state --state NEW -j ACCEPT iptables -A OUTPUT -o $EXTERNAL_INTERFACE1 -p tcp -s $EXTERNAL_IP1 --sport $UNPRIVPORTS --dport 21 -m state --state NEW -j ACCEPT # FTP mark iptables -t mangle -A FORWARD -o $EXTERNAL_INTERFACE1 -p tcp --dport 21 -j MARK --set-mark 0x21 iptables -t mangle -A OUTPUT -o $EXTERNAL_INTERFACE1 -p tcp --dport 21 -j MARK --set-mark 0x21 iptables -t mangle -A PREROUTING -i $INTERNAL_INTERFACE -p tcp --dport 21 -j MARK --set-mark 0x21 iptables -t mangle -A FORWARD -o $EXTERNAL_INTERFACE1 -p tcp --dport 20 -j MARK --set-mark 0x21 iptables -t mangle -A OUTPUT -o $EXTERNAL_INTERFACE1 -p tcp --dport 20 -j MARK --set-mark 0x21 iptables -t mangle -A PREROUTING -i $INTERNAL_INTERFACE -p tcp --dport 20 -j MARK --set-mark 0x21 Do you know how I can mark the related packets to the passive FTP? Regards. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:[EMAIL PROTECTED] | ===Debian=GNU/Linux=== ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] routing TCP to another box preserving ORIGINAL client IPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, : 1) when I add custom rules like : #ip rule add from $BOX_B_ETH1 lookup 3 : it does not take effect for at least 1 minute, perhaps 2-3. : : Why is that? It's quite simple. There is a routing cache. Recently used routes are stored here for faster access. If you would like to empty the routing cache, then you must make your changes to the routing tables and then empty the routing cache: ip route flush cache Be very careful not to omit the word cache. You will have a nice little surprise if you forget the word cache. : This is confusing, since it makes one think that the rule does : not work, while in reality it just has not taken effect. If you'd like to view the route cache: ip route show cache Do you want to see a particular entry? ip route show cache 72.14.203.104 - -Martin - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFF8YC/HEoZD1iZ+YcRAkfFAJ9zYzVRCVMTGE619avs4hZVe+yi2gCgtGRi iCnX/HpQS3PiGIvlaJi7nlo= =S+EQ -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Simple route 2nd look please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, : I want B to route (temporarily) to both the .65 gw and eventually : move to xxx.xxx.xxx.83 being the default gw, but I can't add that : route.. : : I'm missing some obvious, but if someone would take a 2nd look it : would be appreciated. I also have requested to get access to the : switch ,but that's still waiting. This is an L3 problem. After reading your description, I'm guessing that each of your servers has two physical connections to the same L2 (broadcast domain) and you have made modifications to the routing table (at least on Server B) before you tried to solve this problem below. : Server B : ip a s : 1: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 100 :link/ether 00:0b:db:91:84:53 brd ff:ff:ff:ff:ff:ff :inet xxx.xxx.xxx.87/26 brd xxx.xxx.xxx.127 scope global eth0 : 2: eth1: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 100 :link/ether 00:0b:db:91:84:54 brd ff:ff:ff:ff:ff:ff :inet xxx.xxx.xxx.84/32 scope global eth1 : : arping -I eth1 xxx.xxx.xxx.83 : ARPING xxx.xxx.xxx.83 from xxx.xxx.xxx.84 eth1 : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C0] 0.956ms -- Correct interface : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C1] 1.210ms -- Incorrect : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C1] 0.712ms : Unicast reply from xxx.xxx.xxx.83 [00:00:25:C1:CC:C1] 0.711ms I call the above problem ARP flux [0]. It's an extraordinarily common problem when you have multiple connections to the same Ethernet. : ip r s : 127.0.0.0/8 dev lo scope link : default via xxx.xxx.xxx.65 dev eth0 : Unless you are running some weirdo networking startup scripts you have made changes to the routing table or lost routes on this box since you brought up the interface on eth0. Note! The ip address output for eth0 shows that you have an L3 address of 207.135.120.87/26. This means you should have had a network route that looked like this: 207.135.120.64/26 dev eth0 proto kernel scope link src 207.135.120.87 Since this route is missing on Server B, something has removed it. : ip route add default via xxx.xxx.xxx.83 dev eth1 table T1 : RTNETLINK answers: Network is unreachable : eris ~ # route add -net xxx.xxx.xxx.84/31 gw xxx.xxx.xxx.83 : SIOCADDRT: Network is unreachable RTNETLINK is telling you that it has no way to reach 207.135.120.83. You can do two things: * restore the network route, 207.135.120.64/26: ip route add 207.135.120.64/26 dev eth0 src 207.135.120.87 * create a host route to the L3 address you want to use as a next hop: ip route add 207.135.120.83 dev eth0 Good luck! - -Martin [0] http://linux-ip.net/html/ether-arp.html#ether-arp-flux (Sorry for the character encoding mismatch.) - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFF8hdAHEoZD1iZ+YcRAnMNAJ4y+0/GKY3sUEx85IshFuKrCQ4mXwCfeQLO YmGSNeQgmGX8LDGqGySG9CA= =hYRK -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Mark on FTP passive traffic
On Fri, 09 Mar 2007 16:21:02 +0100 Frédéric Massot [EMAIL PROTECTED] wrote: Hi, I use for a customer a Linux router/firewall with 1 internal interface connected to the LAN and 3 external interfaces connected to 3 different ISP. I use a kernel 2.6.17 with a routes patch from Julian Anastasov. I mark outgoing FTP traffic for the routing. With the rules below I do not have a problem with the active/normal FTP to connect on FTP server. But the passive FTP does not pass because I do not know how to mark the related packets whose ports are negotiated in FTP session. I quote only the rules for the internal interface and one of the external interfaces. The rules are the same ones for the three external interfaces. # global rule for all traffic iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # FTP rule iptables -A FORWARD -i $INTERNAL_INTERFACE -o $EXTERNAL_INTERFACE1 -p tcp -s $INTERNAL_LAN --sport $UNPRIVPORTS --dport 21 -m state --state NEW -j ACCEPT iptables -A OUTPUT -o $EXTERNAL_INTERFACE1 -p tcp -s $EXTERNAL_IP1 --sport $UNPRIVPORTS --dport 21 -m state --state NEW -j ACCEPT # FTP mark iptables -t mangle -A FORWARD -o $EXTERNAL_INTERFACE1 -p tcp --dport 21 -j MARK --set-mark 0x21 iptables -t mangle -A OUTPUT -o $EXTERNAL_INTERFACE1 -p tcp --dport 21 -j MARK --set-mark 0x21 iptables -t mangle -A PREROUTING -i $INTERNAL_INTERFACE -p tcp --dport 21 -j MARK --set-mark 0x21 iptables -t mangle -A FORWARD -o $EXTERNAL_INTERFACE1 -p tcp --dport 20 -j MARK --set-mark 0x21 iptables -t mangle -A OUTPUT -o $EXTERNAL_INTERFACE1 -p tcp --dport 20 -j MARK --set-mark 0x21 iptables -t mangle -A PREROUTING -i $INTERNAL_INTERFACE -p tcp --dport 20 -j MARK --set-mark 0x21 Do you know how I can mark the related packets to the passive FTP? Regards. Here's what I'm using to mark ftp traffic for routing purposes, then I use the prerouting chain: # ftp iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 20 -j MARK --set-mark 1000 iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 20 -j MARK --set-mark 1000 iptables -t mangle -A PREROUTING -i eth0 -p tcp --sport 21 -j MARK --set-mark 1000 iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 21 -j MARK --set-mark 1000 iptables -t mangle -A PREROUTING -m helper --helper ftp -j MARK --set-mark 1000 With the use of the ftp_conntrack helper you can match all you ftp traffic, even passive ftp. I hope this can help you. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
