Re: PF and Raptor SMTP gateway incompatible?

["Mike Lewinski" <mike@rockynet.com>]

I think I've tracked this down.... it's also visible under ipfilter on a 2.9
box with very generic configs. For readability the sample IPs below have
been replaced with 'openbsd' and 'raptor'.

We've also gotten sporadic reports of MX connect failures to certain MTA's
with/behind $NEW_FIREWALL_FEATURE (apparently billed as "stopping people
from telnetting on port 25") as follows:

$ uname -a
OpenBSD mx01 2.9 GENERIC#0 i386

ipfilter is enabled at this point (ruleset attached):

mx01# tcpdump -n -s 512 host raptor
tcpdump: listening on xl0
10:35:25.361902 openbsd.6857 > raptor.25:
    S 3681698923:3681698923(0) win 16384
    <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736385 0>
(DF) [tos 0x10]

10:35:25.436022 raptor.25 > openbsd.6857:
    . 612268372:612268396(24) ack 3682698923 win 16384
    (DF) [tos 0x10]

10:35:31.320696 openbsd.6857 > raptor.25:
    S 3681698923:3681698923(0) win 16384
    <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736396 0>
(DF) [tos 0x10]

10:35:31.398016 raptor.25 > openbsd.6857: . 0:24(24) ack 1 win 16384 (DF)
[tos 0x10]

</wash, rinse, repeat>

So their SYN-ACK is missing the SYN needed for three-way handshaking? Let's
see what happens if I disable ipfilter:

mx01# ipf -D
mx01# tcpdump -n -s 512 host raptor
tcpdump: listening on xl0
10:35:53.698465 openbsd.46610 > raptor.25: S 3907864920:3907864920(0) win
16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736441 0>
(DF) [tos 0x10]
10:35:53.773702 raptor.25 > openbsd.46610: . 386102375:386102399(24) ack
3908864920 win 16384 (DF) [tos 0x10]
10:35:53.773781 openbsd.46610 > raptor.25: R 3908864920:3908864920(0) win
16384 (DF)
10:35:59.320944 openbsd.46610 > raptor.25: S 3907864920:3907864920(0) win
16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1284736452 0>
(DF) [tos 0x10]
10:35:59.398854 raptor.25 > openbsd.46610: S 2536349184:2536349184(0) ack
3907864921 win 8760 <mss 1460> (DF)
10:35:59.398935 openbsd.46610 > raptor.25: . ack 1 win 17520 (DF) [tos 0x10]
10:35:59.635440 raptor.25 > openbsd.46610: P 1:48(47) ack 1 win 8760 (DF)
10:35:59.635575 openbsd.46610 > raptor.25: . ack 48 win 17520 (DF) [tos
0x10]
10:36:08.091198 openbsd.46610 > raptor.25: P 1:7(6) ack 48 win 17520 (DF)
[tos 0x10]
10:36:08.165825 raptor.25 > openbsd.46610: P 48:92(44) ack 7 win 8754 (DF)
10:36:08.165914 openbsd.46610 > raptor.25: . ack 92 win 17476 (DF) [tos
0x10]
10:36:08.365233 raptor.25 > openbsd.46610: F 92:92(0) ack 7 win 8754 (DF)
10:36:08.365311 openbsd.46610 > raptor.25: . ack 93 win 17520 (DF) [tos
0x10]
10:36:08.368739 openbsd.46610 > raptor.25: F 7:7(0) ack 93 win 17520 (DF)
[tos 0x10]
10:36:08.441722 raptor.25 > openbsd.46610: . ack 8 win 8754 (DF)
^C
171 packets received by filter
0 packets dropped by kernel

Apparently they will not send a SYN-ACK to setup a connection unless a RST
is received for the first bogus SYN-ACK, while both ipfilter and pf
(3.1-stable) using a fairly generic ruleset appropriate for an MTA block
their bogus packet, preventing any further communications. I've duplicated
this with the same two MTA's across quite a few different boxes.

$ grep raptor /var/log/ipflog | tail -n 3
Jun 14 10:35:25 mx01 ipmon[24954]: 10:35:25.436057              xl0 @0:9 b
raptor,25 -> openbsd,6857 PR tcp len 20 64 -A IN
Jun 14 10:35:31 mx01 ipmon[24954]: 10:35:31.398045              xl0 @0:9 b
raptor,25 -> openbsd,6857 PR tcp len 20 64 -A IN
Jun 14 10:35:43 mx01 ipmon[24954]: 10:35:43.395523              xl0 @0:9 b
raptor,25 -> openbsd,6857 PR tcp len 20 64 -A IN


$ grep -v ^# /etc/ipf.rules
pass in quick on lo0 all
pass out quick on lo0 all
pass in quick on xl0 proto tcp from any to openbsd port = 25
pass out quick on xl0 proto tcp from openbsd to any keep state
pass out quick on xl0 proto udp from openbsd to any keep state
pass out quick on xl0 proto icmp from openbsd to any keep state
block in log on xl0 from any to openbsd

Would someone who knows the RFC requirements better than I do please comment
(reading 793 now...)?

Mike

P.S. I'm not sure what the raptor is really trying to accomplish, since it
isn't stopping anyone from telnetting to port 25...