Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved General pfSense Questions
    6 Posts 2 Posters 4.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      microchip
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • M
        microchip
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • M
          microchip
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • M
            microchip
            last edited by

            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!

            1 Reply Last reply Reply Quote 0
            • M
              microchip
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • D
                doqb
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.