Date: Fri, 15 Nov 2013 10:34:14 +0200 From: salih ahi <salihahi@gmail.com> To: freebsd-ipfw@freebsd.org Subject: ipfw inline rules Message-ID: <CALZybbcSJK_29cDYY4iEEmvixCWJOqZsy16cptqvyHyz9pKc4A@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I have two virtual machines running on VMware with bridge mode network interfaces. I want one of them (FreeBSD) to act as a gateway between the host OS and another VM, which also has bridge interfaces On the FreeBSD machine, I have the following rules installed # tried these rules also with keep-state, nothing changed.. ipfw -q add 00500 divert 44444 log ip from any to any via em2 in ipfw -q add 00510 divert 44444 log ip from any to any via em1 in ip addresses for these interfaces are: em2: 192.168.1.118 em1: 192.168.2.118 This machine stands between a client and server, I want the packets from these two machines to be diverted to my program which listens from a divert socket. client ip is 10.41.1.31 and server has 10.41.2.121. To see if these rules are working correctly, I drop (simply not inject back) every packet with payloads, so TCP handshake should be completed but actual data will not be transmitted When I try to connect the https server from client, I see following lines in /var/log/security Oct 25 16:58:52 legyndir kernel: ipfw: 510 Divert 44444 TCP 10.41.2.121:443 10.41.1.31:15590 in via em1 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.2.121:443 10.41.1.31:15590 in via em1 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.2.121:443 10.41.1.31:15590 out via em2 Oct 25 16:58:52 legyndir kernel: ipfw: 500 Divert 44444 TCP 10.41.1.31:15590 10.41.2.121:443 in via em2 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.1.31:15590 10.41.2.121:443 in via em2 Oct 25 16:58:52 legyndir kernel: ipfw: 600 Accept TCP 10.41.1.31:15590 10.41.2.121:443 out via em1 Oct 25 16:58:52 legyndir kernel: ipfw: 500 Divert 44444 TCP 10.41.1.31:15590 10.41.2.121:443 in via em2 How is it possible that the first records belongs to a packet originating from the server to client and not vice versa? Also, how can the same originating/destination address pairs on the same network interface - as seen on the first two lines- match two different ipfw rules, 510 and 600? And although I only allow packets with payloads to get through in my program, when I run tcpdump on the server, I see packets coming with data: 16:23:31.146387 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [S], seq 1703311588, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 16:23:31.175457 IP 10.41.2.121.443 > 10.41.1.31.21745: Flags [S.], seq 2000005748, ack 1703311589, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:23:31.176048 IP 10.41.2.121.443 > 10.41.1.31.21745: Flags [S.], seq 2000005748, ack 1703311589, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:23:31.176167 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [.], ack 1, win 16425, length 0 16:23:31.176391 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [.], ack 1, win 16425, length 0 16:23:31.177656 IP 10.41.1.31.21745 > 10.41.2.121.443: Flags [P.], seq 1:195, ack 1, win 16425, length 194 16:23:31.178011 IP 10.41.2.121.443 > 10.41.1.31.21745: Flags [.], ack 195, win 123, length 0 What am I missing here??
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALZybbcSJK_29cDYY4iEEmvixCWJOqZsy16cptqvyHyz9pKc4A>