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



  • 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.



  • 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 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!



  • 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?


Log in to reply