Multi-WAN keeps UDP state too long for IAX2 / port 4569

  • We have pfsense set up in a multi-wan environment.  Works fine, as it should.

    However, when we pull the plug on one WAN connection, the Asterisk box CANNOT register across IAX2 (port 4569) to the remote VOIP provider.  This caused me fits trying to debug until I started doing TCPDUMP on each interface.  I realized that the VOIP machine on the LAN was sending IAX2 packets.  The LAN interface on the pfsense was receiving them.  However, it would try to keep sending them out the DOWN WAN interface.  Indefinitely, as far as I can tell.

    This SHOULDN'T be according to this:

    pfctl -st

    tcp.first                    30s
    tcp.opening                  5s
    tcp.established          18000s
    tcp.closing                  60s
    tcp.finwait                  30s
    tcp.closed                  30s
    tcp.tsdiff                  10s
    udp.first                    60s
    udp.single                  30s
    udp.multiple                60s
    icmp.first                  20s
    icmp.error                  10s
    other.first                  60s
    other.single                30s
    other.multiple              60s
    frag                        30s
    interval                    10s
    adaptive.start          120600 states
    adaptive.end            241200 states
    src.track                    0s

    If I go into pfsense and DELETE the two UDP states for the LAN and the "down" WAN interfaces, then the VOIP box immediately is able to "see" the new route through the alternate WAN2 interface.

    We need to fix this somehow.  How do we set pfsense using ANY type of configuration so that it will remove this UDP state sooner.  30-60 seconds would be ok.  But this doesn't happen ever.  It can sit there for minutes on end with no transition from the down WAN to the up WAN2 in the gateway group.

    I have tried setting the firewall settings to both Conservative and Aggressive.  Neither helped.

    ALL OTHER TRAFFIC seems to behave properly.


  • So, lots of views on this topic, but no replies.  Based on previous research on this in the forum before posting this topic, it seems like this IS and HAS BEEN an issue for a long time.  Do the developers not have any input on this?

  • Should this be listed as a bug, or is this an intended feature?  If UDP maintains state longer than the default timeout, it seems like a bug.

Log in to reply