Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 29 replies
  • Subscribers 0 subscribers
  • Views 17434 views
  • Users 0 members are here
Options
Suggested

[BUG][9.004] RED50 starts over and over again after 1 minute

asg_user
The red50 worked in the first place after some time now it starts again and again after 1 minute. A connect to the utm is possible:

2012:10:31-14:33:50 asg-cluster-1 red_server[8520]: SELF: New connection from 1.2.3.4 with ID A340077F21A7426 (cipher AES256-SHA), rev1
2012:10:31-14:33:50 asg-cluster-1 red_server[11258]: SELF: Starting REDv2 protocol
2012:10:31-14:33:50 asg-cluster-1 red_server[11258]: A340077F21A7426: connected OK, pushing config
2012:10:31-14:33:50 asg-cluster-1 red_server[11258]: A340077F21A7426: Sending PEERS+1.2.3.198+192.168.0.3+1.2.3.198
2012:10:31-14:33:53 asg-cluster-1 red_server[11258]: A340077F21A7426: command 'PING 0'
2012:10:31-14:33:54 asg-cluster-1 red_server[11258]: A340077F21A7426: PING remote_tx=0 local_rx=0 diff=0
2012:10:31-14:33:54 asg-cluster-1 red_server[11258]: A340077F21A7426: PONG local_tx=0
2012:10:31-14:33:57 asg-cluster-1 red2ctl[8472]: Received keepalive from reds1:1, enabling peer 1.2.3.4
2012:10:31-14:34:10 asg-cluster-1 red_server[11258]: A340077F21A7426: command 'PING 0'
2012:10:31-14:34:10 asg-cluster-1 red_server[11258]: A340077F21A7426: PING remote_tx=0 local_rx=0 diff=0
2012:10:31-14:34:10 asg-cluster-1 red_server[11258]: A340077F21A7426: PONG local_tx=0
2012:10:31-14:34:21 asg-cluster-1 red_server[8520]: SELF: (Re-)loading device configurations
2012:10:31-14:34:27 asg-cluster-1 red_server[11258]: A340077F21A7426: command 'PING 0'
2012:10:31-14:34:27 asg-cluster-1 red_server[11258]: A340077F21A7426: PING remote_tx=0 local_rx=0 diff=0
2012:10:31-14:34:27 asg-cluster-1 red_server[11258]: A340077F21A7426: PONG local_tx=0
2012:10:31-14:34:47 asg-cluster-1 red2ctl[8472]: Missing keepalive from reds1:1, disabling peer 1.2.3.4
2012:10:31-14:34:58 asg-cluster-1 red_server[11258]: A340077F21A7426: No ping for 30 seconds, exiting.
2012:10:31-14:34:58 asg-cluster-1 red_server[8520]: A340077F21A7426: disconnecting

My setup is:

red50 - firewall (also an ASG V8) - internet - sophos utm 9.004

At the ASG V8 I see that the red50 at first connects to the utm but after that it conntacts the provisioning server again and restarts. Any ideas?

Regards,
Marco
  • 0
    I restored the old config on the fresh installed appliance. After configuring the tunnel again it came back online again. But after a restart of the utm the effect is the same and the utm isn't answering on port 3410 and the red restarts every minute.
  • 0
    I have new information:

    the red_server is answering for the packets on port 3410 but the packets are sent out to the wrong interface and with the wrong source address!?

    I saw this because of this dump:  
    # tcpdump -eni any port 3410
    16:30:23.664898 Out 56:5f:b2:aa:35:f2 ethertype IPv4 (0x0800), length 112: 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68

    (4.4.4.4 is not the real address, but its the ip where the red is behind)

    After further tests the packets are leaving through interface ifb0:

    # tcpdump -eni ifb0 port 3410
    tcpdump: WARNING: ifb0: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ifb0, link-type EN10MB (Ethernet), capture size 376 bytes
    16:30:53.712867 56:5f:b2:aa:35:f2 > 56:5f:b2:aa:35:f2, ethertype IPv4 (0x0800), length 110: 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68

    Maybe this has something to do with the wireless subscription which is active at the interface with the ip 192.168.200.250.
    Changing the allowed networks from the 192.168.200.250 interface to an other interface didn't changed the outgoing traffic of this ifb0 interface:

     # tcpdump -ni ifb0 port 3410
    tcpdump: WARNING: ifb0: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ifb0, link-type EN10MB (Ethernet), capture size 376 bytes
    16:43:34.928863 IP 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68
    16:43:34.928880 IP 192.168.200.250.3410 > 4.4.4.4.1024: UDP, length 68
    16:43:34.928893 IP 192.168.200.250.3410 > 4.4.4.4.1025: UDP, length 68
    16:43:34.928906 IP 192.168.200.250.3410 > 4.4.4.4.1026: UDP, length 68
    16:43:39.936934 IP 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68
    16:43:39.936955 IP 192.168.200.250.3410 > 4.4.4.4.1024: UDP, length 68
    16:43:39.936972 IP 192.168.200.250.3410 > 4.4.4.4.1025: UDP, length 68
    16:43:39.936986 IP 192.168.200.250.3410 > 4.4.4.4.1026: UDP, length 68
    16:43:44.944862 IP 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68
    16:43:44.944879 IP 192.168.200.250.3410 > 4.4.4.4.1024: UDP, length 68
    16:43:44.944891 IP 192.168.200.250.3410 > 4.4.4.4.1025: UDP, length 68
    16:43:44.944903 IP 192.168.200.250.3410 > 4.4.4.4.1026: UDP, length 68
    16:43:49.952846 IP 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68
    16:43:49.952862 IP 192.168.200.250.3410 > 4.4.4.4.1024: UDP, length 68
    16:43:49.952874 IP 192.168.200.250.3410 > 4.4.4.4.1025: UDP, length 68
    16:43:49.952885 IP 192.168.200.250.3410 > 4.4.4.4.1026: UDP, length 68
    16:43:54.960872 IP 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68
    16:43:54.960890 IP 192.168.200.250.3410 > 4.4.4.4.1024: UDP, length 68
    16:43:54.960902 IP 192.168.200.250.3410 > 4.4.4.4.1025: UDP, length 68
    16:43:54.960915 IP 192.168.200.250.3410 > 4.4.4.4.1026: UDP, length 68
    16:43:59.969077 IP 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68
    16:43:59.969095 IP 192.168.200.250.3410 > 4.4.4.4.1024: UDP, length 68
    16:43:59.969107 IP 192.168.200.250.3410 > 4.4.4.4.1025: UDP, length 68
    16:43:59.969120 IP 192.168.200.250.3410 > 4.4.4.4.1026: UDP, length 68
    16:44:04.966390 IP 4.4.4.4.3410 > 1.2.3.198.3410: UDP, length 68
    16:44:04.976884 IP 192.168.200.250.3410 > 4.4.4.4.3410: UDP, length 68
    16:44:04.976903 IP 192.168.200.250.3410 > 4.4.4.4.1024: UDP, length 68
    16:44:04.976916 IP 192.168.200.250.3410 > 4.4.4.4.1025: UDP, length 68
    16:44:04.976928 IP 192.168.200.250.3410 > 4.4.4.4.1026: UDP, length 68

    Marco
  • 0
    I found the "solution". At Interfaces & Routing > Quality of Service (QoS) > Status the WAN interface was active. After disabling this (like the other interfaces) the red 50 tunnel comes online and is working as expected. After enabling the QoS setting again, the tunnel doesn't get up and the effects are as discribed as in posts before. 

    I don't have any traffic selectors or bandwith pools active. It was just the QoS activation for this interface.
  • 0
    Thanks for reporting. We are now tracking this as Mantis ID #23048
  • 0
    Thanks a lot asg_user and maygyver, as both of your RED50 come up with QoS disabled I created a mantis to handle this!
  • 0
    Hello Helmut,

    I installed this update and now the RED 50 is back online (and stays online) with enabled QoS.

    Best regards,
    Marco
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?