PfSense IPSEC and H.323 Avaya IP phones not routing - revisited for pfSense 2.0
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 188.8.131.52 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.
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.
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.
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 184.108.40.206 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 220.127.116.11 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!
Nobody know anything more about this? Is this in the wrong forum, or do I need to provide more information to get it working?
I have exactly the same problem with the AVAYA phone and pfsense. Was anyone able to fix this?