Guest User!

You are not Sophos Staff.

[7.504] RED Communication problems

RED arrived today [:)] Hooray...

Now for the bad stuff...

I did add the RED into the WebAdmin (noticed an issue where the RED ID has to be added in upper case for the letters otherwise the ASG does not recognise the SN).

The red was added without other issues. 

The allowed network was automatically added to the ASG DNS config. However the DHCP server for the RED was NOT created automatically and I had to add it manually!!

I did connect the RED to the network and my notebook to one of its LAN ports.

Then I connected the WAN to the Internet (behind NAT). The RED connects successfully to the ASG and downloads config. I get 4 greens on the RED and ASG says in RED log that all is OK.

However my notebook behind the RED does not receive IP from the DHCP...

Also periodically the System LED on the RED starts blinking. After a while it goes back on but then the tunnel LED goes off and then on again.

In the RED log on the ASG there is an entry that the RED was 'reconnected' and old connection cleared...

2010:03:09-10:44:00 mail red_server[19375]: A30000122C8022A: connected OK, pushing config

2010:03:09-10:44:08 mail red_server[19375]: A30000122C8022A: command 'PING 0'
2010:03:09-10:44:08 mail red_server[19375]: A30000122C8022A: PING remote_tx=0 local_rx=0 diff=0
2010:03:09-10:44:08 mail red_server[19375]: A30000122C8022A: PONG local_tx=0
2010:03:09-10:44:24 mail red_server[19375]: A30000122C8022A: command 'PING 1'
2010:03:09-10:44:24 mail red_server[19375]: A30000122C8022A: PING remote_tx=1 local_rx=1 diff=0
2010:03:09-10:44:24 mail red_server[19375]: A30000122C8022A: PONG local_tx=1
2010:03:09-10:44:40 mail red_server[19375]: A30000122C8022A: command 'PING 6'
2010:03:09-10:44:40 mail red_server[19375]: A30000122C8022A: PING remote_tx=6 local_rx=6 diff=0
2010:03:09-10:44:40 mail red_server[19375]: A30000122C8022A: PONG local_tx=2
2010:03:09-10:45:07 mail red_server[13611]: SELF: New connection from 83.148.8.238 with ID A30000122C8022A
2010:03:09-10:45:07 mail red_server[13611]: A30000122C8022A: already connected, releasing old connection
2010:03:09-10:45:07 mail red_server[13611]: A30000122C8022A: disconnecting
2010:03:09-10:45:10 mail red_server[19648]: A30000122C8022A: connected OK, pushing config 


Any ideas?
  • Here is also the log from the ASG DHCP:

    2010:03:09-11:06:08 mail dhcpd: ip length 328 disagrees with bytes received 338.
    
    2010:03:09-11:06:08 mail dhcpd: accepting packet with data after udp payload.
    2010:03:09-11:06:08 mail dhcpd: DHCPDISCOVER from 00:15:58:ca:42:56 (osklivy-notysek) via reds1
    2010:03:09-11:06:08 mail dhcpd: DHCPOFFER on 192.168.111.254 to 00:15:58:ca:42:56 (osklivy-notysek) via reds1


    Nothing else... No request or ack...
  • This looks like a problem similar to what another participant had - the RED device does not receive the UDP tunnel packets from the ASG. Does the ASG have multiple uplinks?
  • Does the ASG have multiple uplinks?


    Well, yes and no.

    The ASG has 2 physical internet uplinks. However only one has a default GW defined and the other is used via interface routes for VoIP only.

    The RED connects to the main uplink.
  • OK, leave the RED running like it is, then run this tcpdump command in a root ssh shell:

    tcpdump -pni any udp and port 3400

    Leave that running for around 2 minutes and post the output.

    If would also be cool if I could do the debugging myself. If that is OK with you just send the ASG access details to tkistner@astaro.com. Thanks!

    /tom
  • Here is the output of the tcpdump:

    mail:/home/login # tcpdump -pni any udp and port 3400
    
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
    11:52:15.316479 IP 83.148.8.227.3400 > 83.148.8.238.39500: UDP, length 1068
    11:52:15.926010 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 1068
    11:52:26.676597 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 188
    11:52:27.269960 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 220
    11:52:30.280026 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 220
    11:52:31.341065 IP 83.148.8.227.3400 > 83.148.8.238.58292: UDP, length 1068
    11:52:32.003411 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 1068
    11:52:33.291099 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 220
    11:52:33.977636 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 396
    11:52:33.980835 IP 83.148.8.227.3400 > 83.148.8.238.58292: UDP, length 396
    11:52:36.317391 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 220
    11:52:37.986557 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 396
    11:52:37.991517 IP 83.148.8.227.3400 > 83.148.8.238.58292: UDP, length 396
    11:52:39.328192 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 220
    11:52:42.339012 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 220
    11:52:42.963616 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 316
    11:52:45.973916 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 396
    11:52:45.977757 IP 83.148.8.227.3400 > 83.148.8.238.58292: UDP, length 396
    11:52:47.358502 IP 83.148.8.227.3400 > 83.148.8.238.58292: UDP, length 1068
    11:52:48.080813 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 1068
    11:53:01.979864 IP 83.148.8.238.58292 > 83.148.8.226.3400: UDP, length 396
    11:53:01.987205 IP 83.148.8.227.3400 > 83.148.8.238.58292: UDP, length 396
    11:53:21.967504 IP 83.148.8.227.3400 > 83.148.8.238.58292: UDP, length 1068
    11:53:22.786970 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 1068
    11:53:27.282582 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 220
    11:53:30.278152 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 220
    11:53:33.288965 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 220
    11:53:36.315769 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 220
    11:53:37.990085 IP 83.148.8.227.3400 > 83.148.8.238.41035: UDP, length 1068
    11:53:38.862128 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 1068
    11:53:39.326316 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 220
    11:53:42.337138 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 220
    11:53:42.977226 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 316
    11:53:54.024166 IP 83.148.8.227.3400 > 83.148.8.238.41035: UDP, length 1068
    11:53:54.940515 IP 83.148.8.238.41035 > 83.148.8.226.3400: UDP, length 1068
    11:54:29.024845 IP 83.148.8.227.3400 > 83.148.8.238.41035: UDP, length 1068
    11:54:29.649929 IP 83.148.8.238.41901 > 83.148.8.226.3400: UDP, length 1068
    11:54:45.118529 IP 83.148.8.227.3400 > 83.148.8.238.41901: UDP, length 1068
    11:54:45.727824 IP 83.148.8.238.41901 > 83.148.8.226.3400: UDP, length 1068
    11:55:01.139154 IP 83.148.8.227.3400 > 83.148.8.238.41901: UDP, length 1068
    11:55:01.803473 IP 83.148.8.238.41901 > 83.148.8.226.3400: UDP, length 1068
    11:55:35.723812 IP 83.148.8.227.3400 > 83.148.8.238.41901: UDP, length 1068
    11:55:36.511624 IP 83.148.8.238.52287 > 83.148.8.226.3400: UDP, length 1068


    Hope it helps...
  • This is indeed the bug that another tester already found - the ASG answers with the wrong IP address. This bug is fixed in the final 7.504 package which will be hopefully released today.

    In your case, the RED connects to 83.148.8.226, but the ASG answers with the 83.148.8.227. To make this work with the present system, just tell the RED to connect to 83.148.8.227 ("ASG hostname").
  • Hello,

    I deleted the RED (the edit option is missing as mentioned in other threads here).

    While traying to re-add the RED with updated config I get the following error:

    Error while generating RED client certificate.


    It does not matter if I enter the unlock code or not. The error is the same.
  • Hmmm that is weird. That should get deleted automatically.

    1) Turn off RED completely
    2) Go to Certificate Management check if there still is a "red_client" certificate. If yes, delete it.
    3) Turn RED on again, then re-add the device.
  • OK. So after manually deleting the RED client certificate I was able to re-add the RED into the ASG.

    This time the DHCP and DNS entries were created automatically.

    With the primary interface address entered as peer the RED now connects and the tunnel works.

    One question: if the RED is deleted, shouldn't the automatically created DNS allowed network and DHCP entries be deleted automatically as well?
  • The "Quick network setup" is a one-shot thing. It adds the interface, DNS allowed networks entry and the DHCP server. This just serves as a shortcut for quick configuration.

    When you want to move an existing (maybe more complicated) remote network setup, you can just:

    1) Delete existing RED
    2) Add new RED
    3) Edit interface (Network->Interfaces) to use the new RED "hardware".

    All the settings you made for the remote network will stay intact that way.