hi, i think i'm missing something on filtering on the enc interface. scenario looks as:
left secgwA right [internal lan] -- [xl0 tun0] -- ~~ -- [secgwB] -- [other lan] secgwA is a 3.5-stable built on jun 15 (ie. it doesn't have the pf fix that went in the tree on jul 16). on the "right" lan there is an mssql server on 10.80.99.10, and on the left lan there's a client on 192.168.63.4 that needs to access said server. all that needs to be passing through the tunnel is this single connection. secgwB is probably some nortel contivity thing (i wasn't told exactly what it is, but from mail bits i suppose so). secgwA handles only this one ipsec tunnel. a.b.c.142 is the address of secgwA's tun0 interface, d.e.f.2 is the address of secgwB's internet-facing interface. i'm trying to set up filtering on enc0 so that only the above-specified connection may get through, but i'm seeing phenomena i don't really understand (and thus, i'm probably naming several things inappropriately, for i lack a better/proper name for them. i'm trying to be as clear as i can, though, please bear with me). in its simplest form, my pf.conf looks like this: ===== scrub in all fragment reassemble scrub out all fragment reassemble pass quick on lo pass quick on xl0 pass quick on tun0 block log on enc0 pass out log on enc0 proto tcp from 192.168.63.4 to 10.80.99.10 port = 1433 flags S/SA keep state ======== to the best of my knowledge that should be fine, however it doesn't work, and the following can be observed: # tcpdump -s 8192 -nvvvv -e -ttt -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Jul 23 00:49:27.186669 rule 4/0(match): pass out on enc0: 192.168.63.4.48733 > 10.80.99.10.1433: S [tcp sum ok] 1575884958:1575884958(0) win 5840 <mss 1460,sackOK,timestamp 332360117 0,nop,wscale 0> (DF) [tos 0x10] (ttl 63, id 31310) Jul 23 00:49:27.286868 rule 3/0(match): block in on enc0: d.e.f.2 > a.b.c.142: 10.80.99.10.1433 > 192.168.63.4.48733: S [tcp sum ok] 3934513410:3934513410(0) ack 1575884959 win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) (ttl 120, id 45715) (ttl 241, id 27110) the reply packet is what i don't really understand. it would seem to be as if the reply syn+ack was inside another ip packet. this is a problem here, since there never was a packet to which "d.e.f.2 > a.b.c.142" would be a valid reply, so i think the block taking place is actually ok. modifying the ruleset to find out whats going on: ===== scrub in all fragment reassemble scrub out all fragment reassemble pass quick on lo pass quick on xl0 pass quick on tun0 pass log on enc0 ======== this is fine, in the sense that i can establish a connection, but there's no filtering, which is not fine... watching the log, here's what happens: # tcpdump -s 8192 -nvvvv -e -ttt -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Jul 23 01:27:48.754304 rule 3/0(match): pass out on enc0: 192.168.63.4.55423 > 10.80.99.10.1433: S [tcp sum ok] 427950298:427950298(0) win 5840 <mss 1460,sackOK,timestamp 332590275 0,nop,wscale 0> (DF) [tos 0x10] (ttl 63, id 52292) Jul 23 01:27:48.837257 rule 3/0(match): pass in on enc0: d.e.f.2 > a.b.c.142: 10.80.99.10.1433 > 192.168.63.4.55423: S [tcp sum ok] 300042997:300042997(0) ack 427950299 win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) (ttl 120, id 9431) (ttl 241, id 46951) Jul 23 01:27:48.837296 rule 3/0(match): pass in on enc0: 10.80.99.10.1433 > 192.168.63.4.55423: S [tcp sum ok] 300042997:300042997(0) ack 427950299 win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF) (ttl 120, id 9431) Jul 23 01:27:48.837544 rule 3/0(match): pass out on enc0: 192.168.63.4.55423 > 10.80.99.10.1433: . [tcp sum ok] ack 1 win 5840 <nop,nop,timestamp 332590284 0> (DF) [tos 0x10] (ttl 63, id 51598) this i totally don't understand. 1-3-4 seems to be a perfect handshake, but #2 stabs the whole thing in the back, and i'm quite confident that's why the "keep state" approach doesn't work. the interesting thing is that the "d.e.f.2 > a.b.c.142: 10.80.99.10.1433 > 192.168.63.4" `tunnel' notation (i just call it tunnel for now, for lacking a better/proper name for it) only happens in this direction, ie. from "right" to "left". i never ever see anything like "a.b.c.142 > d.e.f.2: 192.168.63.4 > 10.80.99.10.1433" arriving here, i'm all out of ideas. i don't know whether its me, pf, or the contivity thing. as far as i understand, someone is doing something fishy, because the above looks like as if i was seeing only 3/4 part of two connections (or 1.5 parts of one connection, depending how you look at it..) my understanding on the "filtering on enc" was that i'm only supposed to see the the decrypted traffic. well, it seems to be decrypted, but i don't have the slightest idea where does the traffic between the security gateways (and only in one direction!) come in. anyone with some clue? thanks in advance, -- [-] ``Early to rise, early to bed, makes a man healthy, wealthy and dead.''
