Hi,
On Fri, 18.09.2009 at 17:05:51 -0700, Lordsporkton <lordspork...@gmail.com>
wrote:
> Could you send us some actual details? Interface configs, ipsec.conf,
> pf.conf, output of route show, maybe a little network diagram? anything
> so that we actually know what is doing on?
this is one instance of this problem, with some IP numbers mangled:
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33204
priority: 0
groups: lo
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 44:4d:50:09:12:37
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 172.22.0.3 netmask 0xffff0000 broadcast 172.22.255.255
inet6 fe80::464d:50ff:fe09:1237%rl0 prefixlen 64 scopeid 0x1
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 44:40:50:54:44:e5
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 1.2.3.10 netmask 0xfffffffc broadcast 1.2.3.11
inet6 fe80::4640:50ff:fe54:44e5%rl1 prefixlen 64 scopeid 0x2
enc0: flags=41<UP,RUNNING> mtu 1536
priority: 0
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33204
priority: 0
groups: pflog
$ netstat -rnf inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 1.2.3.9 UGS 8 989944 - 8 rl1
1.2.3.8/30 link#2 UC 1 0 - 4 rl1
1.2.3.9 00:1e:f7:dd:e3:7f UHLc 1 0 - 4 rl1
127/8 127.0.0.1 UGRS 0 0 33204 8 lo0
127.0.0.1 127.0.0.1 UH 2 1236 33204 4 lo0
172.22/16 link#1 UC 4 0 - 4 rl0
172.22.0.1/32 link#1 UC 0 0 - 4 rl0
172.22.10.2 link#1 UHLc 0 2 - 4 rl0
172.22.20.1 00:0c:29:3a:70:b0 UHLc 0 39885 - 4 rl0
172.22.20.10 00:15:17:bc:67:e4 UHLc 0 105415 - 4 rl0
172.22.101.4 00:1a:e8:07:96:6b UHLc 0 134 - 4 rl0
224/4 127.0.0.1 URS 0 0 33204 8 lo0
$ netstat -rnf encap
Routing tables
Encap:
Source Port Destination Port Proto
SA(Address/Proto/Type/Direction)
default 0 172.22/16 0 0 5.5.5.5/esp/use/in
172.22/16 0 default 0 0 5.5.5.5/esp/require/out
$ route -n get 172.22.10.2
route to: 172.22.10.2
destination: 172.22.0.0
mask: 255.255.0.0
interface: rl0
if address: 172.22.0.3
priority: 4 (connected)
flags: <UP,DONE,CLONING>
use mtu expire
0 0 -336647
$ ping -q -c 10 172.22.10.2
PING 172.22.10.2 (172.22.10.2): 56 data bytes
--- 172.22.10.2 ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss
# tcpdump -lni enc0 |grep -F icmp
tcpdump: listening on enc0, link-type ENC
15:02:32.466598 (authentic,confidential): SPI 0x5152c74d: 172.22.0.3 >
172.22.10.2: icmp: echo request (encap)
15:02:32.529019 (authentic,confidential): SPI 0x4c36c8fb: 172.22.0.3 >
172.22.10.2: icmp: echo request (encap)
15:02:33.467128 (authentic,confidential): SPI 0x5152c74d: 172.22.0.3 >
172.22.10.2: icmp: echo request (encap)
15:02:33.530162 (authentic,confidential): SPI 0x4c36c8fb: 172.22.0.3 >
172.22.10.2: icmp: echo request (encap)
15:02:34.477035 (authentic,confidential): SPI 0x5152c74d: 172.22.0.3 >
172.22.10.2: icmp: echo request (encap)
The pf rules are mostly saying that all traffic within the private
networks should be passed, and none of them should go out to the
Internet. The interface config files are also very much straightforward.
Example (rl0):
# cat /etc/hostname.rl0
inet 172.22.0.3 255.255.0.0 172.22.255.255
What can be seen in the tcpdump output, is that traffic goes out
to enc0, and thus out to the WAN side of things, when "route get"
indicated that quite the opposite should happen.
Kind regards,
--Toni++
