Nach dem Update auf 9.107-33 eines Sophos UTM 320 und eines UTM 220 HA Clusters hat sich der RED Tunnel (UTM-2-UTM) nicht mehr aufgebaut. Reboot der UTM kommt nicht in Frage… Das muss auch anders gehen 🙂 Also per SSH auf beiden UTM eingeloggen und die Dienste neu starten – wie bei jedem anderen Linuxsystem auch.
Dies ist zum einem der „red_server.plc“ und auf der Gegenseite der „red_client.plc„. Mit „ps fax“ kann man herausfinden welche PID (Prozess-ID) der Service hat:

<M> mfs-fw:/root # ps fax

25970 ?        Ss     0:00 red_server.plc
26001 ?        S      0:00  \_ UPLOAD [idle]
26010 ?        S      0:00  \_ Socket-Listener
26753 ?        S      0:00      \_ 3ca217239ab6d5c (1) [217.6.37.234]

Nun den Serverdienst anhalten (killen!):

<M> mfs-fw:/root # kill -9 25970

Danach blieb der Socket-Listener „hängen“:

2013:12:25-09:02:42 mfs-fw-1 red_server[22797]: Can't open SSL listening socket, re-trying in 10 seconds
 2013:12:25-09:02:52 mfs-fw-1 red_server[22797]: Can't open SSL listening socket, re-trying in 10 seconds
 2013:12:25-09:02:55 mfs-fw-1 red_server[22756]: SELF: shutdown requested, killing clients
 2013:12:25-09:02:55 mfs-fw-1 red_server[22756]: SELF: killing client 3ca217239ab6d5c

Diesen muß man auch mit der Brutalomethode killen:

<M> mfs-fw:/root # kill -9 26010

Jetzt wieder den Dienst neu starten:

<M> mfs-fw:/root # red_server.plc

2013:12:25-09:03:44 mfs-fw-1 red_server[25970]: SELF: RED10rev1 version set to 14
 2013:12:25-09:03:44 mfs-fw-1 red_server[25970]: SELF: RED10rev2 version set to 2005R2
 2013:12:25-09:03:44 mfs-fw-1 red_server[25970]: SELF: RED10rev2 local version set to 2026R2
 2013:12:25-09:03:44 mfs-fw-1 red_server[25970]: SELF: RED50 fw version set to 2005
 2013:12:25-09:03:44 mfs-fw-1 red_server[25970]: SELF: RED50 local fw version set to 2026
 2013:12:25-09:03:44 mfs-fw-1 red_server[25970]: SELF: IO::Socket::SSL Version: 1.953
 2013:12:25-09:03:44 mfs-fw-1 red_server[25970]: SELF: Startup - waiting 15 seconds ...
 2013:12:25-09:03:59 mfs-fw-1 red_server[26001]: UPLOAD: Uploader process starting
 2013:12:25-09:04:00 mfs-fw-1 red_server[25970]: SELF: (Re-)loading device configurations
 2013:12:25-09:04:00 mfs-fw-1 red_server[25970]: 3ca217239ab6d5c: New device
 2013:12:25-09:06:35 mfs-fw-1 red_server[26753]: SELF: New connection from X.X.X.X with ID 3ca217239ab6d5c (cipher RC4-SHA), rev1
 2013:12:25-09:06:35 mfs-fw-1 redctl[26755]: key length: 32
 2013:12:25-09:06:35 mfs-fw-1 redctl[26756]: key length: 32
 2013:12:25-09:06:35 mfs-fw-1 red_server[26753]: 3ca2c7219ab6d5c: connected OK, pushing config
 2013:12:25-09:06:35 mfs-fw-1 red_server[26753]: 3ca2c7219ab6d5c: command 'PING 0'
 2013:12:25-09:06:35 mfs-fw-1 red_server[26753]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="3ca2c7219ab6d5c" forced="0"
 2013:12:25-09:06:35 mfs-fw-1 red_server[26753]: 3ca2c7219ab6d5c: PING remote_tx=0 local_rx=1 diff=-1
 2013:12:25-09:06:35 mfs-fw-1 red_server[26753]: 3ca2c7219ab6d5c: PONG local_tx=0
 2013:12:25-09:06:50 mfs-fw-1 red_server[26753]: 3ca2c7219ab6d5c: command 'PING 10'

Auf der Gegenseite den „red_client.plc“ neu starten. Ebenfalls mit „ps fax“ herausfinden welche PID der Service hat:

<M> as-fw:/root # ps fax

17067 ?        Ss     0:00 red_client.plc
17122 ?        S      0:00  \_ red_client.plc

<M> as-fw:/root # red_client.plc

Logfile sichten:

<M> as-fw:/root # tail -f /var/log/red.log

2013:12:25-09:06:34 as-fw-1 red_client[17067]: SELF: (Re-)loading client configurations
 2013:12:25-09:06:35 as-fw-1 red_client[17067]: Tunnel 1: New client
 2013:12:25-09:06:35 as-fw-1 red_client[17067]: Tunnel 1: Forking client handler
 2013:12:25-09:06:35 as-fw-1 red_client[17122]: CHILD Tunnel 1: performing initial keying.
 2013:12:25-09:06:35 as-fw-1 redctl[17123]: key length: 32
 2013:12:25-09:06:35 as-fw-1 redctl[17124]: key length: 32
 2013:12:25-09:06:35 as-fw-1 redctl[17126]: 21X.125.11.11 =
 2013:12:25-09:06:35 as-fw-1 redctl[17126]:   21X.125.11.11

Nun sollte der Tunnel wieder aufgebaut sein und Traffic darüber laufen: