Announcement

Collapse
No announcement yet.

SD-WAN 1.2 port forwarding bug

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SD-WAN 1.2 port forwarding bug

    hi this is for sd-wan 1.2 on the linksys wrt1900acs
    not to be confused with Untangle NG
    before I posted I spent a good time testing various ways to get port forwarding to work, I tried using regular Untangle NG rules, I tried using the SD-WAN [specific support document] and lastly asked a fellow member here if they could get it working but could not.

    background:
    port forwarding 1701 L2TP vpn port
    ISP does not block 1701, only 25, 80, 443
    testing with windows app 'Simple Port Tester' and various sites.

    Here are my port forwarding rules:
    Code:
    IF packet ip protocol is UDP and server port is 1701 and destination port is 1701, THEN new destination 192.168.1.102
    IF packet destined local is True and ip protocol is UDP and destination port is 1701, THEN new destination 192.168.1.102
    also tried using this rule in the picture:
    Code:
    https://support.untangle.com/hc/article_attachments/360052645513/sd-wanrouter-portforwarding.png
    note: these rules are just in general, i've tried every variation I could think of.

    Thinking I might of done something wrong, I realized Untangle NG has 'Access Rules' as well, so copied a few of them over to SD-WAN configuration:
    Code:
    IF packet ip protocol is UDP and destination port is 1701 and source interface type is LAN [2], THEN accept
    IF packet ip protocol is UDP and destination port is 1701 and source interface type is WAN [1], THEN accept
    also to lump this into the same thread

    I'm experiencing slowish connection establishing, once the webpage is active the rest of the site acts normally, looking over the access rules I tried disabling them to see if things would improve:
    Code:
    Accept established
    IF packet connection state is established, THEN accept
    Accept related
    IF packet connection state is related, THEN accept
    Drop invalid
    IF packet connection state is invalid, THEN drop
    Accept loopback
    IF packet source interface name is "lo", THEN accept
    Lastly, is there future plans to view DHCP leases in the UI? i've had to SSH into the unit and issue the command "cat /tmp/dhcp.leases"

    thanks
    Last edited by sifu; 05-09-2020, 08:46 PM.

  • #2
    Is there an easy way to test this?

    Comment


    • #3
      I believe you are correct. I see the packets on the WAN but not on the LAN.
      Attention: Support and help on the Untangle Forums is provided by
      volunteers and community members like yourself.
      If you need Untangle support please call or email [email protected]

      Comment


      • #4
        regarding the LAN
        can you verify what the delay is on the initial connection?
        i.e.
        Code:
        Pinging 1.1.1.1 with 32 bytes of data:
        Reply from 1.1.1.1: bytes=32 time=[COLOR=#ff0000][B]554ms[/B][/COLOR] TTL=252
        Reply from 1.1.1.1: bytes=32 time=3ms TTL=252
        Reply from 1.1.1.1: bytes=32 time=3ms TTL=252
        Reply from 1.1.1.1: bytes=32 time=3ms TTL=252
        any freshly visited site i visit always has a delay, as long as the session sticks around the site remains quick

        testing from within SD-WAN via SSH does not cause the above issue.
        so i suspect its something to do with LAN side.

        Comment

        Working...
        X
        😀
        🥰
        🤢
        😎
        😡
        👍
        👎