UDP issue on 3.5 and 3.6 new installs

Home Page Forums Network Management ZeroShell UDP issue on 3.5 and 3.6 new installs

This topic contains 3 replies, has 0 voices, and was last updated by  iulyb 2 years, 4 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #44599

    iulyb
    Member

    Hi,

    My SIP device a Linksys / Cisco SPA 3102 doesn’t register anymore using UDP port 5060 when using 3.5 and then 3.6 after a reboot.
    Worked flawless for more than 4 years with older versions.

    Going into firewall section and then on conntrack press flush seems to fix it until the next reboot.

    Even more interesting this issue doesn’t appear on a device that has been upgraded, just on new installs.

    #54183

    DrmCa
    Participant

    FWIW my Linksys PAP2T continued to work with 3.5 after upgrage from 3.0
    AFAIK they do not require any setup to work and as long as firewall is not blocking the address/port/protocol everything should be hunky-dory.

    #54184

    iulyb
    Member

    @drmca wrote:

    FWIW my Linksys PAP2T continued to work with 3.5 after upgrage from 3.0
    AFAIK they do not require any setup to work and as long as firewall is not blocking the address/port/protocol everything should be hunky-dory.

    That is correct, forgot to mention, I have an upgrade setup and works ok on that, on the new install doesn’t.

    I have no rules so you are right, no setup is required.
    There is a bug open on the ddwrt on this issue related to contrack. This is how I figure out the workaround to do contrack flush.

    #54185

    DrmCa
    Participant

    Sorry, I probably mislead you!
    Mine was a brand new install of 3.5 where I restored a backup taken under 3.0. It was an “upgrade” in terms of going up a version only, not that I installed 3.5 over 3.0.

    In your brand new install do you have any forwarding under virtual server at all? Any chance 5060 or the RTP ports are forwarded to a wrong host?

    #54186

    iulyb
    Member

    @drmca wrote:

    Mine was a brand new install of 3.5 where I restored a backup taken under 3.0. It was an “upgrade” in terms of going up a version only, not that I installed 3.5 over 3.0.

    In your brand new install do you have any forwarding under virtual server at all? Any chance 5060 or the RTP ports are forwarded to a wrong host?

    Thanks,
    This is good to know. I do not have any rules under virtual server.
    I have an Alix box and an APU box.
    On Alix I started with some 2.x version then applied upgrades.
    On APU I started with 3.5 then applied upgrades. I never imported config, I just redid a similar config having a real domain (not example.com.. )

    Besides the hardware differences, I changed the network IP from 192.168.0.75 to 192.168.5.5 in order to have more flexibly on VPN.

    Here is the output of iptables:

    iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    SYS_GUI all -- anywhere anywhere
    SYS_INPUT all -- anywhere anywhere
    SYS_HTTPS tcp -- anywhere anywhere tcp dpt:http
    SYS_HTTPS tcp -- anywhere anywhere tcp dpt:https
    SYS_SSH tcp -- anywhere anywhere tcp dpt:ssh

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    SYS_OUTPUT all -- anywhere anywhere

    Chain NetBalancer (0 references)
    target prot opt source destination

    Chain SYS_DNS (2 references)
    target prot opt source destination
    ACCEPT all -- 192.168.5.0/24 anywhere
    ACCEPT all -- 192.168.5.0/24 anywhere
    ACCEPT all -- 192.168.5.0/24 anywhere
    ACCEPT all -- 192.168.250.0/24 anywhere
    ACCEPT all -- 192.168.15.0/24 anywhere
    DROP all -- anywhere anywhere

    Chain SYS_GUI (1 references)
    target prot opt source destination
    ACCEPT tcp -- 192.168.250.1 anywhere tcp dpt:12081

    Chain SYS_HTTPS (2 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- 192.168.5.0/24 anywhere
    ACCEPT all -- 192.168.5.0/24 anywhere
    ACCEPT all -- 192.168.5.0/24 anywhere
    ACCEPT all -- 192.168.250.0/24 anywhere
    ACCEPT all -- 192.168.15.0/24 anywhere
    DROP all -- anywhere anywhere

    Chain SYS_INPUT (1 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere anywhere udp spt:domain state ESTABLISHED
    ACCEPT tcp -- anywhere anywhere tcp spt:domain state ESTABLISHED
    SYS_DNS udp -- anywhere anywhere udp dpt:domain
    SYS_DNS tcp -- anywhere anywhere tcp dpt:domain
    ACCEPT tcp -- anywhere anywhere tcp spt:http state ESTABLISHED
    ACCEPT tcp -- anywhere anywhere tcp spt:8245 state ESTABLISHED
    ACCEPT udp -- anywhere anywhere udp spt:ntp state ESTABLISHED
    RETURN all -- anywhere anywhere

    Chain SYS_OUTPUT (1 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere anywhere udp dpt:domain
    ACCEPT tcp -- anywhere anywhere tcp dpt:http
    ACCEPT tcp -- anywhere anywhere tcp dpt:8245
    ACCEPT udp -- anywhere anywhere udp dpt:ntp
    RETURN all -- anywhere anywhere

    Chain SYS_SSH (1 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- 192.168.5.0/24 anywhere
    ACCEPT all -- anywhere anywhere
    DROP all -- anywhere anywhere

    I did more investigation and here are the results:

    after reboot:

    root@zs scripts> conntrack -L |grep 5060
    udp 17 3598 src=192.168.5.56 dst=85.204.232.10 sport=5060 dport=5060 packets=718 bytes=341879 [UNREPLIED] src=85.204.232.10 dst=192.168.5.56 sport=5060 dport=5060 packets=0 bytes=0 mark=0 use=1

    Then flush table fix the issue

    root@zs scripts> conntrack -F
    root@zs scripts> conntrack -L |grep 5060
    udp 17 3588 src=192.168.5.56 dst=85.204.232.10 sport=5060 dport=5060 packets=1 bytes=428 src=85.204.232.10 dst=154.20.113.39 sport=5060 dport=5060 packets=1 bytes=393 mark=0 use=1

    When I get some time I will switch the configs between the 2 devices to exclude the HW as a culprit and keep you posted.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.