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
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
