Hi all,
I've got a VPN running between two networks. Works fine for basically
everything and very easy to setup, kudos to the guys that worked on
ipsecctl and isakmpd.
I have one problem though that I am trying to debug.
Network looks like this:
192.168.11.250 # Asterisk1
|
|
192.168.11.1 # OpenBSD1 4.3
|
| # VPN
|
192.168.4.1 # OpenBSD2 4.3
|
|
192.168.4.250 # Asterisk2
Firstly, I can ssh from any box to any box over the VPN. This works
fine. So the basic VPN is functional.
Secondly, 192.168.4.1 has several different routes out of it and a
fairly complex setup in pf.conf and this is what I think I have
misconfigured.
I am trying to setup an IAX2 (port 4569) from asterisk1 to asterisk2.
The traffic is running and I get the traffic flowing from one end to
the other, but return traffic is getting blocked or misrouted.
Tcpdump on 192.168.4.250 eth0 I see the packets from 192.168.11.250
arriving and packets from 192.168.4.250 leaving.
Tcpdump on 192.168.4.1 enc0 I see the packets from 192.168.11.250
arriving and packets from 192.168.4.250 leaving.
Tcpdump on 192.168.11.1 enc0 I only see the 192.168.11.250 packets.
Tcpdump on 192.168.11.250 eth0 I only see the 192.168.11.250 packets.
I have disabled any firewalls on both asterisk boxes, but this makes no change.
Disabling pf on the 192.168.11.1 box makes no change.
I can't disable pf on 192.168.4.1 right now (could schedule a time later)
I believe the problem is somewhere in 192.168.4.1's pf.conf or route table.
Now, I know this email contains no where near all the data needed to
debug this by someone on list, but I want to work it out myself and I
have a few questions.
1) Is the ipsec tunnel just treated like a standard interface by PF?
2) how and when does the ipsec tunnel grab packets to send through the
tunnel? I can't see any route entries or the like. I assume it
attaches somehow the same way PF does and intercepts packets.
And probably most importantly:
3) What is the best way to find what rule in PF is matching the IAX
UDP packet stream? I'm not getting anywhere with eyeballing it.
If I can find how the packet is moving through the stack, I am sure I
can fix the darn thing.
Thanks
Mikel
