Date: Wed, 12 Nov 2008 17:22:13 -0500 From: FreeBSD <freebsd@optiksecurite.com> To: freebsd-pf@freebsd.org Subject: RDR not triggered Message-ID: <491B5715.8040601@optiksecurite.com>
next in thread | raw e-mail | index | archive | help
Hi everyone, I'm a little confused as to why my RDR is not working. Quick explanation of my setup: We have 2 webservers, a frontend and a backend. The frontend have a jail for Lighttpd (images server) and Apache on the base system (for PHP). There is one public IP associated to the jail on the public side of the frontend server. There is only one internal private IP. The jail is bound to 127.0.0.25 and a RDR on the external interface is redirecting the traffic in the jail when the request arrive with it's public IP as destination. rdr on $EXT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD port http That's working great for external connections. The problem is that the backend server needs to access the Lighttpd jail by the public IP of the frontend server. I understand that I can't redirect the traffic inside the jail with a RDR on the external interface because the packets didn't passthrough the interface. That's why I created I copy of the above RDR but on the internal interface. rdr on $INT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD port http That rule is never triggered even when the traffic, according to tcpdump, is corresponding to the criteria. At the moment, the RDR for the internal interface is just before the external one. The pfctl -gvvvsn output for these 2 rules: @0 rdr on bge1 inet proto tcp from any to 66.AAA.BB.66 port = http -> 127.0.0.25 port 80 [ Skip steps: d=end f=9 p=9 sa=end sp=12 da=2 dp=2 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 91246 Packets: 0 Bytes: 0 States: 0 ] @1 rdr on bge0 inet proto tcp from any to 66.AAA.BB.66 port = http -> 127.0.0.25 port 80 [ Skip steps: i=9 d=end f=9 p=9 sa=end sp=12 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 91246 Packets: 3261224 Bytes: 2403004153 States: 2531 ] The tcpdump -nevvvi output from the internal interface of the frontend (where the RDR is not triggered) 17:16:24.683316 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 53680, offset 0, flags [DF], proto: TCP (6), length: 60) 10.0.0.11.61428 > 66.AAA.BB.66.80: S, cksum 0x8827 (correct), 766260635:766260635(0) win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 2883659146 0> 17:16:24.683342 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 59837, offset 0, flags [DF], proto: TCP (6), length: 64, bad cksum 0 (->b615)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: S, cksum 0xf1e7 (correct), 2408882600:2408882600(0) ack 766260636 win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 605433816 2883659146,sackOK,eol> 17:16:24.683520 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53681, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: ., cksum 0x112c (correct), 1:1(0) ack 1 win 8326 <nop,nop,timestamp 2883659147 605433816> 17:16:24.683672 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 265: (tos 0x0, ttl 64, id 53682, offset 0, flags [DF], proto: TCP (6), length: 251) 10.0.0.11.61428 > 66.AAA.BB.66.80: P 1:200(199) ack 1 win 8326 <nop,nop,timestamp 2883659147 605433816> 17:16:24.684461 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 545: (tos 0x0, ttl 64, id 59838, offset 0, flags [DF], proto: TCP (6), length: 531, bad cksum 0 (->b441)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: P 1:480(479) ack 200 win 33304 <nop,nop,timestamp 605433817 2883659147> 17:16:24.684803 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53683, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: F, cksum 0x0e83 (correct), 200:200(0) ack 480 win 8326 <nop,nop,timestamp 2883659148 605433817> 17:16:24.684823 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 59839, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->b61f)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: ., cksum 0xacef (correct), 480:480(0) ack 201 win 33304 <nop,nop,timestamp 605433818 2883659148> 17:16:24.684845 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 59840, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->b61e)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: F, cksum 0xacee (correct), 480:480(0) ack 201 win 33304 <nop,nop,timestamp 605433818 2883659148> 17:16:24.684956 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53684, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: ., cksum 0x0e82 (correct), 201:201(0) ack 481 win 8325 <nop,nop,timestamp 2883659148 605433818> Nothing is blocked on both of the servers. The packets are simply not redirected and passed to the Apache on the base system of the frontend server instead of going in the Lighttpd jail, only when coming the the internal network. I'm using FreeBSD 6.2 on the frontend and 7.0 on the backend. Thanks everyone for helping me shed some light on this Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?491B5715.8040601>