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

    Suricata Pass List using Hostnames?

    Scheduled Pinned Locked Moved IDS/IPS
    3 Posts 2 Posters 1.6k 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.
    • P
      pfBasic Banned
      last edited by

      On part of my network I use a Gateway group comprised of VPN clients (Private Internet Access) as the only gateways.

      Running suricata I've noticed that it eventually starts blocking the VPN client IP's (I think because it is pinging me on unused ports). So I'll end up with packet loss leading to offlining the gateway. Restarting the VPN's just shuts down the gateway again. If I clear Suricata's block list then all is well.

      I tried to create an alias of PIA's hostnames then use that alias as a passlist on suricata but I get an error:

      FQDN aliases are not supported in Suricata.
      

      Is there some way that I can whitelist hostnames on Suricata to avoid this?

      PIA Hostnames:

      us-california.privateinternetaccess.com
      us-east.privateinternetaccess.com
      us-midwest.privateinternetaccess.com
      us-chicago.privateinternetaccess.com
      us-texas.privateinternetaccess.com
      us-florida.privateinternetaccess.com
      us-seattle.privateinternetaccess.com
      us-west.privateinternetaccess.com
      us-siliconvalley.privateinternetaccess.com
      us-newyorkcity.privateinternetaccess.com
      uk-london.privateinternetaccess.com
      uk-southampton.privateinternetaccess.com
      ca-toronto.privateinternetaccess.com
      ca.privateinternetaccess.com
      aus.privateinternetaccess.com
      aus-melbourne.privateinternetaccess.com
      nz.privateinternetaccess.com
      nl.privateinternetaccess.com
      sweden.privateinternetaccess.com
      no.privateinternetaccess.com
      denmark.privateinternetaccess.com
      fi.privateinternetaccess.com
      swiss.privateinternetaccess.com
      france.privateinternetaccess.com
      germany.privateinternetaccess.com
      ireland.privateinternetaccess.com
      italy.privateinternetaccess.com
      ro.privateinternetaccess.com
      turkey.privateinternetaccess.com
      kr.privateinternetaccess.com
      hk.privateinternetaccess.com
      sg.privateinternetaccess.com
      japan.privateinternetaccess.com
      israel.privateinternetaccess.com
      mexico.privateinternetaccess.com
      brazil.privateinternetaccess.com
      in.privateinternetaccess.com
      
      1 Reply Last reply Reply Quote 0
      • J
        jeffhammett
        last edited by

        As far as I know it's not possible to use hostnames in the passlist.

        Depending on how often PIA changes IP addresses, you may be able to enumerate all IPs from all the FQDNs you posted and add those to the passlist. If they don't change often this could work long term, or at least improve things. PIA may even publish the IP ranges or CIDR's they use, which would make this easier.

        Another approach would be to determine what rule is causing the PIA IPs to get blocked and either disable it entirely or suppress it for these IPs (again, you would need to determine all of the IPs involved)

        Last, if they're truly getting blocked for pinging on unused ports, you could move Suricata from your WAN interface (where I'm assuming it would be running in that scenario) to the LAN, so then the pinging of unused ports would be blocked by the firewall and wouldn't be seen by Suricata.

        1 Reply Last reply Reply Quote 0
        • P
          pfBasic Banned
          last edited by

          OK thank you, I figured that would be the answer.

          I ended up just disabling & modifying some rules so that it's no longer a problem.

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