PfSense IPSEC and H.323 Avaya IP phones not routing - revisited for pfSense 2.0

[microchip]

Hi,

I originally tried to set up an IPsec link between two pfSense boxes a while ago here in the old forums, and got nowhere with trying to get the Avaya IP phones to cooperate, where they'd worked fine over the old Cisco PIX 501 to pfSense 1.2.3 link. However, since upgrading the pfSense box at our main office to 2.0, we'd been having trouble with the PIX link (namely it going up and down a lot!) so I thought I'd give it another go with the pfSense 2.0 setup. And yet again, it brought me a whole world of pain.

As a quick recap, our warehouse network here is on 192.168.10.0/24 (with the pfSense box being .1), and our main office network is on 192.168.1.0/24 (with the pfSense box as .1 again). The IP office unit is at 192.168.1.201, and the HTTP/TFTP server is at 192.168.1.202 for their configuration / firmware. The two pfSense boxes are connected over IPsec using blowfish encryption, and every other protocol is working fine. I also tried over OpenVPN to see if that made any difference, and got precisely the same results.

I've enabled the TFTP proxy which seems to work, but the phones just sit on "Discovering 192.168.1.201…", and the following lines appear in a packet capture over and over (translated by Wireshark):

23	0.965169	192.168.10.57	192.168.1.201	H.225.0	354	RAS: gatekeeperRequest

(.55 and .57 are the VoIP phones here that ran happily over the PIX->pfSense bridge).

I've followed the instructions at http://doc.pfsense.org/index.php/VoIP_Configuration as well. It was hanging on the TFTP stage, but adding a NAT rule - strangely from 192.168.1.202 to 192.168.1.202 on port 69 seems to have stopped it hanging, although it may not have actually solved anything.

Running a packet capture on the office pfSense box doesn't show anything at all from .55 and .57 on the LAN network in question, and the same running a packet capture on the IPsec link - it looks like the traffic simply isn't going anywhere. There's a "permit any" on both sides of the IPsec firewall setup, and no sign of the traffic attempting to leave on the local WAN interface.

The only thing in the firewall logs that seems to be being blocked is IGMP, such as below:

Nov 1 16:05:16	WAN	   192.168.1.254	   224.0.0.1	IGMP

It's beginning to get quite frustrating, as I can't seem to figure out what I'm missing here at all. If anyone has any insight, or suggestions of where I should be capturing packets to trace it, I'd really appreciate it, but the gatekeeper requests seem to stop at the warehouse pfSense box, and never make it to the main office. This is the exact problem I had last time, which I couldn't fix, and ended up reverting back to the Cisco PIX, which did forward the packets that made it work. I'm guessing there's a problem either with the TFTP communication or actually at the part where it's getting stuck and asking for the gatekeeper, but I'm not entirely sure which.

[microchip]

I've set the TFTP proxy to be on for the LAN side, and removed the port 69 NAT. The phones behaved as they were.

I then put a laptop between the phone and the pfSense box, bridged the wired and wireless connections together (the wireless connects to the same switch as the wire did, and then straight to pfSense) - the TFTP transfers time out, but to my surprise, the phone then logged on to the IP office, and was able to make and receive calls! This confused the hell out of me. Packet capture is at http://db.tt/KhbrDibH (tcpdump/pcap format) - I'm going to find an old unswitched hub to see if I can get a direct capture, to find out what is going on, and eliminate whatever "fix" the bridge is creating.

[microchip]

Putting it through an old hub reverted it to it's previous behaviour. Capture file is at http://db.tt/KhbrDibH for the failed registration via the hub. I'm now going to run it through the old Cisco PIX and observe the behaviour, along with associated capture files, so hopefully someone can diagnose the issue and help anyone else with these Avaya IP phones and pfSense.

[microchip]

Put the PIX back in, and it's working fine again now. Capture is at http://db.tt/Xqt83iUG for the working registration, the same as what happened when the machine was bridged between them.

PIX configuration (cleaned for certain external IP monitoring):

warehouse# wr term
Building configuration...
: Saved
:
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password [XXXXXXX] encrypted
passwd [XXXXXXX] encrypted
hostname warehouse
domain-name xxx.local
clock summer-time BST recurring 4 Sun Mar 2:00 4 Sun Oct 2:00
fixup protocol dns maximum-length 512
fixup protocol ftp 21
no fixup protocol h323 h225 1720
no fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
no fixup protocol tftp 69
names
name 192.168.10.1 in-warehouse
name xx.xx.xx.xx out-warehouse
name 94.194.32.123 out-hq
name 192.168.1.200 in-dns1
name 192.168.1.0 HQNetwork
name 192.168.10.0 WarehouseNetwork
access-list inside_outbound_nat0_acl permit ip WarehouseNetwork 255.255.255.0 HQNetwork 255.255.255.0
access-list outside_cryptomap_20 permit ip WarehouseNetwork 255.255.255.0 HQNetwork 255.255.255.0
access-list acl-outside permit icmp any any echo-reply
access-list acl-outside permit icmp any any source-quench
access-list acl-outside permit icmp any any unreachable
access-list acl-outside permit icmp any any time-exceeded
access-list acl-inside permit icmp any any
access-list acl-inside permit udp host 192.168.1.1 any eq domain
access-list acl-inside permit udp any any eq domain
access-list acl-inside permit tcp any any eq www
access-list acl-inside permit tcp any any eq https
access-list acl-inside permit tcp any any eq ftp
access-list acl-inside permit udp any any eq isakmp
access-list acl-inside permit udp any any eq ntp
access-list acl-inside permit udp any any eq 4500
access-list acl-inside permit tcp any any eq domain
access-list acl-inside permit ip WarehouseNetwork 255.255.255.0 HQNetwork 255.255.255.0
access-list acl-inside permit tcp any any eq 3389
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside xx.xx.xx.x 255.255.248.0

ip address inside in-warehouse 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm location HQNetwork 255.255.255.0 outside
pdm location 192.168.1.1 255.255.255.255 inside
pdm location HQNetwork 255.255.255.0 inside
pdm location 0.0.0.0 255.255.248.0 outside
pdm location 0.0.0.0 255.255.255.255 outside
pdm location 192.168.20.0 255.255.255.0 inside
pdm location 192.168.20.0 255.255.255.0 outside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group acl-outside in interface outside
access-group acl-inside in interface inside
route outside 0.0.0.0 0.0.0.0 94.194.32.1 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http HQNetwork 255.255.255.0 inside
http WarehouseNetwork 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection tcpmss 1500
sysopt connection permit-ipsec
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto map map_warehouse 1 ipsec-isakmp
crypto map map_warehouse 1 match address outside_cryptomap_20
crypto map map_warehouse 1 set pfs group2
crypto map map_warehouse 1 set peer out-hq
crypto map map_warehouse 1 set transform-set ESP-AES-256-SHA
crypto map map_warehouse 1 set security-association lifetime seconds 86400 kilobytes 4608000
crypto map map_warehouse interface outside
crypto map map-warehouse 1 ipsec-isakmp
! Incomplete
isakmp enable outside
isakmp key ******** address out-hq netmask 255.255.255.255 no-xauth no-config-mode
isakmp identity address
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption aes-256
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 28800
telnet timeout 5
ssh WarehouseNetwork 255.255.255.0 inside
ssh HQNetwork 255.255.255.0 inside
ssh timeout 5
console timeout 0
dhcpd address 192.168.10.50-192.168.10.80 inside
dhcpd dns in-dns1 xx.xx.xx.xx
dhcpd wins in-dns1
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd domain BoundaryBathrooms.local
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Cryptochecksum:xxxxxxxxxxxxxxxxxxxxxxxxx
: end
[OK]

Apparently the only firewall "out of the box" that Avaya supports is the PIX - it'd be nice to add pfSense to the list of firewalls those phones would run across for VPN!

[microchip]

Nobody know anything more about this? Is this in the wrong forum, or do I need to provide more information to get it working?

[doqb]

I have exactly the same problem with the AVAYA phone and pfsense. Was anyone able to fix this?