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

    PfSense IPSEC and H.323 Avaya IP phones not routing

    Scheduled Pinned Locked Moved IPsec
    6 Posts 3 Posters 6.5k 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 everyone,

      I've replaced a Cisco PIX 505 unit at our warehouse with a pfSense box, as the Cisco seemed a little unreliable when connected to our other pfSense box at our head office. They're set up with an IPSEC VPN between them, which is working fantastically with Blowfish, Windows networking etc is also working fantastically.

      However, I've been having trouble with the IP phone system since swapping it over. The phones will request an updated firmware via TFTP from the voicemail / TFTP server (which goes through fine), but will then get stuck attempting to communicate with the actual IP office box, repeatedly sending out a UDP request (according to the packet capture I fed into Wireshark: "22 2.613203 192.168.10.55 192.168.1.201 H.225.0 RAS: gatekeeperRequest"). 192.168.10.0/24 is our warehouse network, 192.168.1.0/24 is our head office network. While doing this, the phone sits on "Discovering 192.168.1.201…" and can't get any further. I've verified the configuration on the phones, and all looks correct - IP address, router, phone server, etc.

      I captured packets on both sides, and it clearly shows the TCP requests getting through (TFTP and HTTP), but the UDP packets aren't arriving on the other side of the network (at our head office). I also noticed that attempting to use our head office DNS as an override for our internal domain didn't work, as it couldn't contact the DNS server, which may indicate UDP packets not being routed. UDP is now confirmed working across the link, as I did an nslookup from one of these machines using the domain controller as the lookup server. Pinging works from both sides each way, as do all TCP operations. The firewalls are set to allow all IPSEC traffic on both sides (protocol any). I also set both firewalls to "Conservative" settings, and tried setting any connections to the IP Office to static, and even tried disable NAT, to no avail.

      I don't know if it's relevant, but the VPN is established between one of the WAN connections at head office to the single WAN connection at the warehouse, and the IPSEC link is set up between 192.168.10.0 and 192.168.1.0 - the latter being OPT1 on the pfSense box at the office (configured as one of our LANs, with our servers connected to it.) There were no previous problems with the PIX to pfSense setup (except for it being unreliable and a little slow), and nothing except for the encryption type and key has been altered on the IPSEC setup on the head office side.

      I've been scratching my head for hours… if anyone can shed a little light on this, I'd appreciate it!

      As a side-note, I'm not averse to changing over to an OpenVPN link if it'd solve my issues, I just haven't dealt with OpenVPN yet.

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

        I attempted an OpenVPN link, to no avail, exactly the same happened. I've checked everything I can here - the TFTP over UDP works fine, HTTP access works fine, it's just the request on 1719 that doesn't make it to the other side for no apparent reason. Everything else seems to work just fine, including Windows networking access. ???

        I'm really quite lost as to why this isn't working now. I'll retrieve the previous PIX setup and see if I can figure out what the difference is…

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

          Can't see anything in the previous setup that is relevant. The only things that were there of potential interest were:

          no fixup protocol h323 h225 1720
          no fixup protocol h323 ras 1718-1719
          no fixup protocol tftp 69

          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

          I can't see anything else at all. I've just ordered the book, perhaps that'll help me find what I'm looking for…

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            Have you done a packet capture on each interface individually to see if the traffic is exiting a different interface than expected?

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

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

              Checking the WAN captures just showed standard internet-based traffic (mainly HTTP from the computers), with no sign of anything from the phone. The LAN captures showed the data arriving from the phone, but it never got to the other side of the VPN link when running the capture on each interface there.

              I've temporarily replaced the PIX there, and got the phones up and running, and brought the pfSense PC back to our main office. I'm going to get hold of another IP phone and set up a test VPN, to see if I can reproduce it in a non-live environment.

              1 Reply Last reply Reply Quote 0
              • O
                oxigen
                last edited by

                Hello  sir

                Now I try to set up IPsec Box with Pfsense for H323 avaya IP phone too, I have already  config for IPSec Mobile client  but I found
                the status of IPSec it show the yellow creoss sign not  GREEN , How I can enable this service. But I make sure I have already checked enable IPsec and IPsec Mobile client .

                Thank you

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