comes in from enc0 is ip-in-ip encapsulated (Protocol 04) and addressed
to our outside address.
The solution to the problem comes from the fact that once the ip-in-ip
packet is passed by an ipf rule like:
pass in quick on enc0 proto ip from any to <EXTERNAL-ADDR>
the encapsulation is stripped off and the original packet comes back in
through enc0 with the internal machine's address in the destination. At
that point, it can be processed by ipf inbound rules based on the original
source/destination/protocol like:
pass in quick on enc0 proto icmp from any to <INTERNAL-ADDR> icmp-type echo
A sample of the packets from 'ipmon -bxt' follow:
30/10/2002 13:52:57.095454 enc0 @0:17 p 65.59.108.65 -> 193.221.14.229 PR ip len 20 (80) IN
45 80 50 00 70 06 00 00 75 04 a9 26 41 3b 69 18 E.P.p...u.�&A;lA
43 53 3b 2e 45 00 00 3c 06 6f 00 00 80 01 7b d2 CS;.E..<.o....{�
41 3b 6c 41 0a 01 01 03 08 00 de 5a 02 00 6d 01 A;lA......�Z..m.
61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
30/10/2002 13:52:57.095477 enc0 @0:18 p 65.59.108.65 -> 10.1.1.3 PR icmp len 20 60 icmp echo/0 IN
45 00 3c 00 06 6f 00 00 80 01 7b d2 41 3b 6c 41 E.<..o....{�A;lA
0a 01 01 03 08 00 de 5a 02 00 6d 01 61 62 63 64 ......�Z..m.abcd
65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 efghijklmnopqrst
75 76 77 61 62 63 64 65 66 67 68 69 uvwabcdefghi
As far as I know, this capability is only available under OpenBSD.
Bob
At 02:42 PM 10/28/02 -0500, you wrote:
I am running OpenBSD 3.1 with IPFilter 3.4.29. I would like to filter
inbound IPsec traffic entering via the enc0 interface based on the internal
destination addresses (10.1.1.0/24). The problem I am having is that the
packets coming from enc0 to ipf still contain the IP headers with the address
of the tunnel end-point (193.221.14.229), instead of just the included tcp,
udp or icmp packets as they would come from a standard interface. The
following is output from 'ipmon -bxt':
27/10/2002 12:34:17.650807 enc0 @0:13 b 65.59.105.24 -> 193.221.14.229 PR ip len 20 (80) IN
45 80 50 00 a4 1a 00 00 75 04 78 3b 41 3b 69 18 E.P.�...u.x;A;i.
c1 dd oe e5 45 00 00 3c 1a a3 00 00 80 01 6a c7 CS;.E..<.�....j�
41 3b 69 18 0a 01 01 03 08 00 46 5c 02 00 05 00 A;i.......F\....
61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
27/10/2002 12:35:25.559314 enc0 @0:13 b 65.59.105.24 -> 193.221.14.229 PR ip len 20 (68) IN
45 80 44 00 bd 1a 00 40 75 04 1f 47 41 3b 69 18 E.D.�[EMAIL PROTECTED];i.
c1 dd oe e5 45 00 00 30 1a bc 40 00 80 06 2a b5 CS;.E..0.�@...*�
41 3b 69 18 0a 01 01 03 0b ec 03 e7 ca a7 19 62 A;i......�.�ʧ.b
00 00 00 00 70 02 22 38 b7 b3 00 00 02 04 05 b4 ....p."8��.....�
01 01 04 02 ....
Is there any way to get at the included packets with ipf on the inbound
side? I can probably set up outbound rules to filter the traffic, but
that means setting up rules on multiple interfaces. I also prefer to
use inbound rules in order make the block/pass decisions as early as
possible in the processing cycle.
Thanks for any assistance.
Bob
