Avaya 9650 NAT-T and ipfw

N

nixlike

I have an Avaya 9650 IP Phone that leverages and IPSec VPN tunnel that it creates in order to connect to the internal devices at the far end and operate. The tunnel looks like it gets established as I can see successful completion of phase 1 and phase 2. What happens next has been frustrating me since yesterday. The udp-encap esp packets that flow from the phone "disappear in FreeBSD (the firewall I use at home). I have a very simple setup that allows all traffic originating in the network out.

Code: 
[root@barker /usr/src/sys/i386/conf]# ipfw -a list
00100     34     6104 allow ip from any to any via lo0
00200      0        0 deny ip from any to 127.0.0.0/8
00300      0        0 deny ip from 127.0.0.0/8 to any
00400      0        0 deny ip from any to ::1
00500      0        0 deny ip from ::1 to any
00600     16     1024 allow ipv6-icmp from :: to ff02::/16
00700      0        0 allow ipv6-icmp from fe80::/10 to fe80::/10
00800    268    20000 allow ipv6-icmp from fe80::/10 to ff02::/16
00900      0        0 allow ipv6-icmp from any to any ip6 icmp6types 1
01000      0        0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
62000      0        0 allow log esp from any to any
62001      0        0 allow log ah from any to any
62002      0        0 allow log ipencap from any to any
63000     44     9572 allow log ip from 192.168.0.125 to any
64000    297    19230 allow log ip from any to 192.168.0.125
65000 127768 45220220 allow ip from any to any
65535      0        0 deny ip from any to any

I have also explicitly created two rules to log anything to and from the Avaya phone to see if I can understand what's going on.

Code: 
Mar 15 11:41:43 barker kernel: ipfw: 64000 Accept UDP xxx.xxx.xxx.xxx:4500 192.168.0.125:4500 in via tun0
Mar 15 11:41:43 barker kernel: ipfw: 64000 Accept UDP xxx.xxx.xxx.xxx:4500 192.168.0.125:4500 out via dc0
Mar 15 11:42:03 barker kernel: ipfw: 64000 Accept UDP xxx.xxx.xxx.xxx:4500 192.168.0.125:4500 in via tun0
At the same time I am running tcpdump to log any packets seen on the internal interface for the ethernet address of the avaya phone.

Code: 
11:41:43.055334 IP remotevpn.com.sae-urn > 192.168.0.125.sae-urn: isakmp-nat-keep-alive
11:41:45.474035 IP 192.168.0.125.sae-urn > remotevpn.com.sae-urn: UDP-encap: ESP(spi=0x2adcbeb9,seq=0x16), length 372
11:41:50.869500 IP 192.168.0.125.sae-urn > remotevpn.com.sae-urn: UDP-encap: ESP(spi=0x2adcbeb9,seq=0x17), length 372

Note the two packets at the end are not logged in the firewall logs that I am collecting, the packets are clearly seen on the interface but do not appear to submitted to ipfw somehow and passed through the firewall to it's final destination. The next packet logged on the firewall is a packet originating from the remote side to "keep alive" the ipsec tunnel.

My question is, what am I doing wrong or not understanding that would allow these packets to be processed by ipfw and subsequently passed to the final destination? Any insight is greatly appreciated.

I upgraded this morning to FreeBSD release 9 just to make sure I was at the most recent release prior to asking for someone's time in regards to my delima.

Code: 
FreeBSD barker.nixlike.com 9.0-STABLE FreeBSD 9.0-STABLE #3: Thu Mar 15 08:38:35 EDT 2012     
[email]root@barker.nixlike.com[/email]:/usr/obj/usr/src/sys/barker  i386

Is it necessary to compile a custom kernel with crypto and IPSEC references if I simply want to pass those packets along untouched (beyond NAT'ing of course)?

Thank you.
Jim Barker
 
So, you want your FreeBSD box to be the nat/ipfw gateway passing through IPsec VPN from/to your IP phone

Did I understand this correctly? If yes, why do you think that nat/ipfw would work without having any nat related rules in your ipfw ruleset?
 
Good observation Rolfheinrich. The nat'ing is actually being handled by the PPPoe NAT'ing functionality. But I am really concerned about the lack of an entry in the firewall log regarding the incoming packet that I see on the interface during tcpdump. It doesn't even get to a point where a translation would happen judging by the lack of the entry.

Code: 
ppp_enable="yes"                # Start user-ppp (or NO).
ppp_mode="ddial"                # Choice of "auto", "ddial", "direct" or "dedicated".
                        # For details see man page for ppp(8). Default is auto.
ppp_nat="YES"           # Use PPP's internal network address translation or NO.

Code: 
[root@barker /etc/ppp]# cat ppp.conf
#################################################################
# PPP  Sample Configuration File
# Originally written by Toshiharu OHNO
# Simplified 5/14/1999 by wself@cdrom.com
#
# See /usr/share/examples/ppp/ for some examples
#
# $FreeBSD: src/etc/ppp/ppp.conf,v 1.12.2.1 2011/09/23 00:51:37 kensmith Exp $
#################################################################

default:
# set log Phase Chat LCP IPCP CCP tun command
 set log Phase tun command
# ident user-ppp VERSION (built COMPILATIONDATE)

 # Ensure that "device" references the correct serial port
 # for your modem. (cuau0 = COM1, cuau1 = COM2)
 #
# set device /dev/cuad1

# set speed 115200
# set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
           \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
# set timeout 180                       # 3 minute idle timer (the default)
 enable dns                             # request DNS info (for resolv.conf)
# set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
 set ifaddr 10.0.0.1/0 10.0.0.2/0

papchap:
 #
 # edit the next three lines and replace the items in caps with
 # the values which have been assigned by your ISP.
 #

 set phone PHONE_NUM
 set authname USERNAME
 set authkey PASSWORD

 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
 add default HISADDR                    # Add a (sticky) default route

verizon:
 set device PPPoE:fxp0
 set authname <myauthname>
 set authkey <mykey>
 set dial
 set login
 add default HISADDR
 
nixlike said:
... It doesn't even get to a point where a translation would happen judging by the lack of the entry.

Code: 
ppp_enable="yes"                # Start user-ppp (or NO).
ppp_mode="ddial"                # Choice of "auto", "ddial", "direct" or "dedicated".
                        # For details see man page for ppp(8). Default is auto.
ppp_nat="YES"           # Use PPP's internal network address translation or NO.
Click to expand...

Here comes an excerpt from the man page of rc.conf(5)():
Code: 
ppp_nat     (bool) If set to “YES”, enables network address translation.
                 Used in conjunction with gateway_enable allows hosts on pri‐
                 vate network addresses access to the Internet using this host
                 as a network address translating router.

You didn't mention that you set
Code: 
gateway_enable="YES"
in /etc/rc.conf. Did you set it?
 
rc.conf

Rolfheinrich,

Yes, I do have gateway_enable set to yes in /etc/rc.conf. Phase 1 and Phase 2 wouldn't have completed without nat'ing and the gateway setting being enabled. Even if they weren't set, it still doesn't elude to why I don't see an entry in the firewall logs for the incoming packet on the internal interface, at the very least I should have seen that. That is the mystery I am dealing with. Why hasn't those packets been processed by the firewall at all. I think that is where my troubles are. Thanks for inquiring, keep the questions coming, hopefully something will click and help me with an ah ha moment.

Regards,
Jim Barker
 
expectations

Is this potentially a bug that I am dealing with? Are there more tools I can use to see how the packets are being processed within the FreeBSD box? I know dtrace is part of FreeBSD now, are there appropriate probes to help with my situation?
 
ipsec sysctl "dropping" packets

I have been reading the man page for ipsec and there are a lot of sysctl variables that control how the kernel processes packets related to ipsec.

http://www.freebsd.org/cgi/man.cgi?query=ipsec&sektion=4&manpath=FreeBSD+8.0-RELEASE

Can it be that the kernel is acting on these packets even though it's not the destination of the packet?

I think I am getting closer. Any kernel folks monitoring the ipfw forum that can chime in?
 
I didn't notice this before, but the packet has some 802.1q references when I run tcpdump with the -e option.
Code: 
19:45:51.833768 00:1b:4f:55:54:74 (oui Unknown) > 00:04:5a:74:c9:67 (oui Unknown), ethertype 802.1Q (0x8100), length 418: vlan 0, p 6, ethertype IPv4,
 192.168.0.125.sae-urn > myvpn.com.sae-urn: UDP-encap: ESP(spi=0xc6e2650c,seq=0x4), length 372

I ran a cisco vpn client connecting to the same host and didn't see any such references.

Code: 
19:47:48.945476 00:04:5a:74:c9:67 (oui Unknown) > 00:50:bf:9a:da:80 (oui Unknown), ethertype IPv4 (0x0800), length 142: myvpn.com.sae-urn >
 opensolaris-virtualbox.57895: UDP-encap: ESP(spi=0x9723ee8d,seq=0x13), length 100

I also noticed that if I ran
Code: 
tcpdump -i dc0 host 192.168.0.125
instead of
Code: 
tcpdump -i dc0 ether host 00:1b:4f:55:54:74
I don't see those packets destined for the vpn host anymore. I don't know that the firewall forum is the most appropriate forum for this issue at this point.
 
Ok, I now have the phone working. I did the following.

1. Configured the phone to use vlan 2 instead of vlan 0.
2. ifconfig vlan0 create.
3. ifconfig vlan0 vlan 2 vlandev dc0.

After that FreeBSD didn't ignore the 802.1Q packets and I got a dial tone.

This should probably be referenced in a more appropriate forum.
 
You must log in or register to reply here.
Back
Top