I never really thought about. It works fine when my rules are:
pass out proto udp from any to 192.168.1.50 port = 111 keep frags
pass in proto udp from 192.168.1.50 port = 111 to any keep frags
pass out proto udp from any to 192.168.1.91 port = 111 keep frags
pass in proto udp from 192.168.1.91 port = 111 to any keep frags
But it only works some of the time and hangs the rest of the time when
I change it to:
pass out proto udp from any to any port = 111 keep state keep frags
Doing a tcpdump, when it hangs I'm seeing:
---------------------------------------------------------------------------
Packet 1
TIME: 14:23:34.722496
LINK: 08:00:20:8F:DF:D9 -> 00:0B:BF:CB:EC:CA type=IP
IP: 192.168.1.1 -> 192.168.1.50 hlen=20 TOS=00 dgramlen=84 id=268D
MF/DF=0/1 frag=0 TTL=255 proto=UDP cksum=4F15
UDP: port 32808 -> sunrpc hdr=8 data=56
DATA: >.G"....................................................
---------------------------------------------------------------------------
Packet 2
TIME: 14:23:34.723355 (0.000859)
LINK: 00:0B:BF:CB:EC:CA -> 08:00:20:8F:DF:D9 type=IP
IP: 192.168.1.91 -> 192.168.1.1 hlen=20 TOS=00 dgramlen=56 id=5F8D
MF/DF=0/0 frag=0 TTL=63 proto=UDP cksum=1A5A
UDP: port sunrpc -> 32808 hdr=8 data=28
DATA: >.G".......................Z
---------------------------------------------------------------------------
Packet 3
TIME: 14:23:50.035682 (15.312327)
LINK: 08:00:20:8F:DF:D9 -> 00:0B:BF:CB:EC:CA type=IP
IP: 192.168.1.1 -> 192.168.1.50 hlen=20 TOS=00 dgramlen=84 id=268E
MF/DF=0/1 frag=0 TTL=255 proto=UDP cksum=4F14
UDP: port 32814 -> sunrpc hdr=8 data=56
DATA: >.=.....................................................
---------------------------------------------------------------------------
Packet 4
TIME: 14:23:50.036499 (0.000817)
LINK: 00:0B:BF:CB:EC:CA -> 08:00:20:8F:DF:D9 type=IP
IP: 192.168.1.91 -> 192.168.1.1 hlen=20 TOS=00 dgramlen=56 id=608D
MF/DF=0/0 frag=0 TTL=63 proto=UDP cksum=195A
UDP: port sunrpc -> 32814 hdr=8 data=28
DATA: >.=........................Z
---------------------------------------------------------------------------
and the logs show:
May 27 14:23:35 hostname ipmon[118]: 14:23:34.723176 le0 @0:4 b 192.168.1.91,111 ->
192.168.1.1,32808 PR udp len 20 56 IN
May 27 14:23:50 hostname ipmon[118]: 14:23:50.036380 le0 @0:4 b 192.168.1.91,111 ->
192.168.1.1,32814 PR udp len 20 56 IN
When it works I see:
---------------------------------------------------------------------------
Packet 1
TIME: 14:23:55.458987 (5.422488)
LINK: 08:00:20:8F:DF:D9 -> 00:0B:BF:CB:EC:CA type=IP
IP: 192.168.1.1 -> 192.168.1.91 hlen=20 TOS=00 dgramlen=84 id=268F
MF/DF=0/1 frag=0 TTL=255 proto=UDP cksum=533B
UDP: port 32816 -> sunrpc hdr=8 data=56
DATA: >.C.....................................................
---------------------------------------------------------------------------
Packet 2
TIME: 14:23:55.459611 (0.000624)
LINK: 00:0B:BF:CB:EC:CA -> 08:00:20:8F:DF:D9 type=IP
IP: 192.168.1.91 -> 192.168.1.1 hlen=20 TOS=00 dgramlen=56 id=618D
MF/DF=0/0 frag=0 TTL=63 proto=UDP cksum=185A
UDP: port sunrpc -> 32816 hdr=8 data=28
DATA: >.C........................Z
---------------------------------------------------------------------------
The machine has multiple DNS records, if that matters:
;; ANSWER SECTION:
some.machine.net. 10800 IN A 192.168.1.50
some.machine.net. 10800 IN A 192.168.1.91
The reverse DNS for both IPs points to some.machine.net.
Dan
Jim Sandoz writes:
>
> dan,
>
> never mind getting ipf's "keep state" to work in this
> situation, how do you think tcp/ip is going to work?
>
> example, based on your description...
>
> host A sends to host B an opening TCP gambit...
> 192.168.1.10:1024 -> 192.168.1.50:80 TCP SYN
>
> are you saying that "sometimes" host B responds...
> 192.168.1.91:80 -> 192.168.1.10:1024 TCP SYN+ACK ???
>
> sorry, but from host A's tcp/ip stack/kernel perspective
> this appears as an unsolicited packet, and is thus dropped.
> that is, there is no mating socket tuple on host A.
> how does the stack know where to plug the payload in?
> if indeed host B is behaving like this, it's broken.
>
> either my understanding of your problem is skewed or
> we need another chapter in "TCP/IP Illustrated".
> and man-in-the-middle attacks just got a lot easier.
>
> jim
>
>
> Dan D Niles wrote:
> > Is there any way to get state to work with hosts that don't
> > always send replies with the same address?
> >
> > I have a server that has two interfaces and two IPs. If I send
> > a packet to 192.168.1.50, sometimes the response comes back on
> > 192.168.1.50 and sometimes it comes back on 192.168.1.91 (not the
> > real IPs). When the response comes back on 50, state works fine
> > but when it comes back on 91, it doesn't.
> >
> > I have also seen this problem with virtual hosts on solaris.
> >
> > Thanks,
> >
> > Dan
>
>
