Thread Info
  • State Suggested Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 39 replies
  • Answers 2 answers
  • Subscribers 13 subscribers
  • Views 148790 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Disconnect Loop RED 15 -

reFresh

Hi,

ich have a very strange problem with the new RED 15.

Setting:

UTM 9.350-12 at the main office

RED 15 with static IP behind an LTE-router at the remote location

After the first configuration everything works fine. But after some hours the RED diconnect and reconnected every minute.

After a reboot of the UTM (or if i deactivate the RED for some hours)  the connection is stable for some hours.

Here are some lines out of the RED log:

2015:11:10-16:42:48 che-igw01 red_server[20657]: A350124B7XXXXXX: command 'PING 0 uplink=WAN'
2015:11:10-16:42:48 che-igw01 red_server[20657]: A350124B7XXXXXX: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:42:48 che-igw01 red_server[20657]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:42:52 che-igw01 red_server[20939]: SELF: New connection from 2.200.175.176 with ID A350124B7XXXXXX: (cipher AES256-GCM-SHA384), rev1
2015:11:10-16:42:52 che-igw01 red_server[20939]: A350124B7XXXXXX:: already connected, releasing old connection.
2015:11:10-16:42:52 che-igw01 red_server[20657]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A350124B7XXXXXX" forced="1"
2015:11:10-16:42:52 che-igw01 red_server[20657]: A350124B7XXXXXX: is disconnected.
2015:11:10-16:42:52 che-igw01 red2ctl[4266]: Overflow happened on reds2:0
2015:11:10-16:42:52 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:42:52 che-igw01 red_server[4255]: SELF: (Re-)loading device configurations
2015:11:10-16:42:53 che-igw01 red_server[20939]: A350124B7XXXXXX:: connected OK, pushing config
2015:11:10-16:42:53 che-igw01 red_server[20939]: A350124B7XXXXXX:: Sending PEERS+178.15.XXX.XXX
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'UMTS_STATUS value=OK'
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:42:57 che-igw01 red_server[20939]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A350124B7XXXXXX:" forced="0"
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:42:57 che-igw01 red_server[20939]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:42:58 che-igw01 red_server[4255]: SELF: (Re-)loading device configurations
2015:11:10-16:42:59 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:43:02 che-igw01 red2ctl[4266]: Received keepalive from reds2:0, enabling peer 2.200.XXX.XXX
2015:11:10-16:43:11 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:43:11 che-igw01 red_server[20939]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:43:11 che-igw01 red_server[20939]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:43:26 che-igw01 red_server[20939]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:43:26 che-igw01 red_server[20939]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:43:26 che-igw01 red_server[20939]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:43:30 che-igw01 red_server[21136]: SELF: New connection from 2.200.XXX.XXX with ID A350124B7XXXXXX: (cipher AES256-GCM-SHA384), rev1
2015:11:10-16:43:30 che-igw01 red_server[21136]: A350124B7XXXXXX:: already connected, releasing old connection.
2015:11:10-16:43:30 che-igw01 red_server[20939]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A350124B7XXXXXX:" forced="1"
2015:11:10-16:43:31 che-igw01 red_server[20939]: A350124B7XXXXXX: is disconnected.
2015:11:10-16:43:31 che-igw01 red_server[4255]: SELF: (Re-)loading device configurations
2015:11:10-16:43:32 che-igw01 red2ctl[4266]: Overflow happened on reds2:0
2015:11:10-16:43:32 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:43:32 che-igw01 red_server[21136]: A350124B7XXXXXX:: connected OK, pushing config
2015:11:10-16:43:32 che-igw01 red_server[21136]: A350124B7XXXXXX:: Sending PEERS+178.15.XXX.XXX
2015:11:10-16:43:35 che-igw01 red2ctl[4266]: Overflow happened on reds2:0
2015:11:10-16:43:35 che-igw01 red2ctl[4266]: Missing keepalive from reds2:0, disabling peer 2.200.XXX.XXX
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: command 'UMTS_STATUS value=OK'
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: command 'PING 0 uplink=WAN'
2015:11:10-16:43:35 che-igw01 red_server[21136]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A350124B7XXXXXX:" forced="0"
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: PING remote_tx=0 local_rx=0 diff=0
2015:11:10-16:43:35 che-igw01 red_server[21136]: A350124B7XXXXXX:: PONG local_tx=0
2015:11:10-16:43:41 che-igw01 red2ctl[4266]: Received keepalive from reds2:0, enabling peer 2.200.XXX.XX
Other RED devices (RED10) at the same UTM works fine.
Any ideas?



This thread was automatically locked due to age.
Parents
  • 0
    I also have the same problem with RED15. RED10 works fine. The logs look identical to the OP. Ports are not blocked in the modems (either end) as far as I can tell. Is it an issue with having mixed generations (RED10 and RED15) on the same UTM?

    ------------

    Kevin

  • 0 in reply to Kevin_Miller

    Hi Kevin,

    I will conduct further testing tomorrow and let you know the results.

    From my experience, I have been able to get RED10 and RED15 working perfectly on the same UTM.

    Thanks,

    Ted

  • 0 in reply to TedReynolds

    Hi Kevin,

    You can check the firewall logs in real time with this command:

    utm:/root # tail -fn0 /var/log/packetfilter.log | grep [ip address of the destination]

    2015:11:30-01:17:27 utm ulogd[4647]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth2" srcmac="xx:xx:xx:xx:xx:xx" srcip="x.x.x.x" dstip="184.72.39.13" proto="6" length="60" tos="0x10" prec="0x00" ttl="64" srcport="42912" dstport="3410" tcpflags="SYN"

    In this case you can tell the packets are being dropped due to a default drop action in the OUTPUT chain in iptables.

    To verify the correct entries have been added to iptables for your UTM, run iptables -L INPUT && echo -e '\n' && iptables -L OUTPUT

    IPtables that includes the correct rules for the RED 10 and RED 15 communication:

    utm:/root # iptables -L INPUT && echo -e '\n' && iptables -L OUTPUT
    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere anywhere udp spts:tcpmux:65535 dpt:redv2-data
    ACCEPT tcp -- anywhere anywhere tcp spts:tcpmux:65535 dpt:networklenss
    ACCEPT udp -- anywhere anywhere udp spts:tcpmux:65535 dpt:red-data
    ACCEPT tcp -- anywhere anywhere tcp spts:tcpmux:65535 dpt:red-control
    ACCEPT all -- anywhere !base-address.mcast.net/4 CONFIRMED match
    CONFIRMED all -- anywhere anywhere ctstate RELATED
    HA_IN all -- anywhere anywhere
    LOCKOUT all -- anywhere anywhere
    PSD_MATCH all -- anywhere anywhere
    SANITY_CHECKS all -- anywhere anywhere
    AUTO_INPUT all -- anywhere anywhere
    USR_INPUT all -- anywhere anywhere
    LOGDROP all -- anywhere anywhere LOGMARK match 60001


    Chain OUTPUT (policy DROP)
    target prot opt source destination
    LOGDROP tcp -- !loopback/8 anywhere tcp spts:1024:65535 dpt:webadmin LOGMARK match 60005
    LOGDROP tcp -- !loopback/8 anywhere tcp spts:tcpmux:65535 dpt:prchat-user LOGMARK match 60005
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere anywhere udp spts:tcpmux:65535 dpt:redv2-data
    ACCEPT tcp -- anywhere anywhere tcp spts:tcpmux:65535 dpt:networklenss
    ACCEPT udp -- anywhere anywhere udp spts:tcpmux:65535 dpt:red-data
    ACCEPT tcp -- anywhere anywhere tcp spts:tcpmux:65535 dpt:red-control
    ACCEPT all -- anywhere !base-address.mcast.net/4 CONFIRMED match
    CONFIRMED all -- anywhere anywhere ctstate RELATED
    CONFIRMED all -- anywhere anywhere -m condition --condition "OUTPUT_ACCEPT_ALL" owner UID match root owner GID match root
    HA_OUT all -- anywhere anywhere
    SANITY_CHECKS all -- anywhere anywhere
    AUTO_OUTPUT all -- anywhere anywhere
    USR_OUTPUT all -- anywhere anywhere
    LOGDROP all -- anywhere anywhere LOGMARK match 60003

    IPtables that does not have the required rules in place:

    utm:/root # iptables -L INPUT && echo -e '\n' && iptables -L OUTPUT
    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- anywhere !base-address.mcast.net/4 CONFIRMED match
    CONFIRMED all -- anywhere anywhere ctstate RELATED
    HA_IN all -- anywhere anywhere
    LOCKOUT all -- anywhere anywhere
    PSD_MATCH all -- anywhere anywhere
    SANITY_CHECKS all -- anywhere anywhere
    AUTO_INPUT all -- anywhere anywhere
    USR_INPUT all -- anywhere anywhere
    LOGDROP all -- anywhere anywhere LOGMARK match 60001


    Chain OUTPUT (policy DROP)
    target prot opt source destination
    LOGDROP tcp -- !loopback/8 anywhere tcp spts:1024:65535 dpt:webadmin LOGMARK match 60005
    LOGDROP tcp -- !loopback/8 anywhere tcp spts:tcpmux:65535 dpt:prchat-user LOGMARK match 60005
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- anywhere !base-address.mcast.net/4 CONFIRMED match
    CONFIRMED all -- anywhere anywhere ctstate RELATED
    CONFIRMED all -- anywhere anywhere -m condition --condition "OUTPUT_ACCEPT_ALL" owner UID match root owner GID match root
    HA_OUT all -- anywhere anywhere
    SANITY_CHECKS all -- anywhere anywhere
    AUTO_OUTPUT all -- anywhere anywhere
    USR_OUTPUT all -- anywhere anywhere
    LOGDROP all -- anywhere anywhere LOGMARK match 60003

    In case IPtables contains the correct rules and you are still not able to connect on port 3410, I would run a packet capture to determine what is happening to the traffic. For instance, this packet capture captures any UDP packets on any interface using port 3410.

    utm:/root # tcpdump -tttt -ni any udp port 3410 -vvv -s 0

    Depending on the results, I would look at any upstream devices and contact your ISP to verify all communication is open for TCP 3400 and UDP 3410. 

  • 0 in reply to TedReynolds

    Hi Ted,

    The first command doesn't display anything for the 30 or so minutes that I let it run.

    The IPTables contain to correct rules as per your post.

    I ran the tcpdump and it seemed to be sending and receiving  (i've included the log below - omitting public IP). The ISP says they don't block any ports and that I can run any service on any port. So I'm at a loss now. Strangley the RED50 devices we tried deploying to 2 different end user sites (different UTMs and ISPs all) earlier in the year had to be replaced with old RED10s we had in stock because they exhibited the same issues. Do they also use the v2 protocol like the RED15?

    220.xxx.xxx.xxx.3410 > 10.0.1.1.3410: [udp sum ok] UDP, length 68
    2015-12-01 14:40:54.788916 IP (tos 0x0, ttl 58, id 44328, offset 0, flags [none], proto UDP (17), length 96)
        220.xxx.xxx.xxx.3410 > 10.0.1.1.3410: [udp sum ok] UDP, length 68
    2015-12-01 14:40:55.057838 IP (tos 0x0, ttl 64, id 3148, offset 0, flags [none], proto UDP (17), length 96)
        10.0.1.1.3410 > 220.xxx.xxx.xxx.3410: [udp sum ok] UDP, length 68
    2015-12-01 14:40:55.557819 IP (tos 0x0, ttl 64, id 3198, offset 0, flags [none], proto UDP (17), length 96)
        10.0.1.1.3410 > 220.xxx.xxx.xxx.3410: [udp sum ok] UDP, length 68
    2015-12-01 14:40:55.742757 IP (tos 0x0, ttl 58, id 44330, offset 0, flags [none], proto UDP (17), length 96)
        220.xxx.xxx.xxx.3410 > 10.0.1.1.3410: [udp sum ok] UDP, length 68
    2015-12-01 14:40:55.742785 IP (tos 0x0, ttl 58, id 44330, offset 0, flags [none], proto UDP (17), length 96)
        220.xxx.xxx.xxx.3410 > 10.0.1.1.3410: [udp sum ok] UDP, length 68
    1610 packets captured
    1610 packets received by filter
    0 packets dropped by kernel

    ------------

    Kevin

  • 0 in reply to Kevin_Miller

    Hi Kevin,

    In your original post you mentioned that the setup was using:

    "RED 15 with static IP behind an LTE-router at the remote location"

    When the RED 15 was first setup, did it contact a DHCP server as the first connection, then have the static IP settings configured?

    Thanks,

    Ted

Reply
  • 0 in reply to Kevin_Miller

    Hi Kevin,

    In your original post you mentioned that the setup was using:

    "RED 15 with static IP behind an LTE-router at the remote location"

    When the RED 15 was first setup, did it contact a DHCP server as the first connection, then have the static IP settings configured?

    Thanks,

    Ted

Children
  • 0 in reply to TedReynolds

    Hi Ted,

    The original poster is reFresh. I just joined the discussion because I was having the same issue.

    I will try and give you as much info on the setup as I can.

    The RED15 is operating in Standard / Unified Mode. It has a single UTM hostname in config (which is an IP). The Uplink Mode is DHCP Client. The RED network is setup in the DHCP relay to the Internal Windows Server DHCP range.

    Internal LAN: 10.0.0.0/24 with the Windows Server (DNS/DHCP) on 10.0.0.1 and UTM on 10.0.0.254

    RED LAN: 10.0.3.0/24 with DHCP Relay set in the Network services on the UTM pointing to the Windows Server.

    DHCP Range setup on Windows Server: with the gateway being: 10.0.3.254.

    To give you more info on my client's setup here is the RED network definition on the Web Admin info tab.

    Used in these configurations:
      Wireless Protection → Global Settings → Global Settings
      Interfaces & Routing → Interfaces
      Network Protection → NAT → Masquerading
      Web Protection → Web Filter Profiles → Filter Profiles
      Network Protection → Firewall → Rules
      Interfaces & Routing → Quality of Service (QoS) → Status
      Network Services → DHCP → Relay
      Wireless Protection → Access Points
     
     
    Used by these objects:
    01) Network Protection → Firewall → Rules → DNS from Internal (Network) to Any
    02) Network Protection → Firewall → Rules → Any from RED (Network) to Internal (Network)
    03) Interfaces & Routing → Interfaces → Interfaces → 10.0.3.254/24
     
      Wireless Protection → Global Settings → Global Settings
      Interfaces & Routing → Interfaces
      Interfaces & Routing → Quality of Service (QoS) → Status
      Network Services → DHCP → Relay
      Wireless Protection → Access Points
     
    04) Network Protection → Firewall → Rules → Web Surfing from Internal (Network) to Any
    05) Network Protection → Firewall → Rules → Any from Internal (Network) to RED (Network)
    06) Web Protection → Web Filter Profiles → Filter Profiles → Default Web Filter Profile
     
      Web Protection → Web Filter Profiles → Filter Profiles
     
    07) Network Protection → Firewall → Rules → Any from Internal (Network) to itriver.com.au
    08) Network Protection → Firewall → Rules → Citrix 1 from Internal (Network) to Citrix Servers
    09) Network Protection → NAT → Masquerading → from RED (Network) to External (WAN)
     
      Network Protection → NAT → Masquerading
     
    10) Network Protection → Firewall → Rules → FTP from Internal (Network) to Any (2)

    ------------

    Kevin

Unfiltered HTML