Hi there,
I have a strange problem with an internet connection on an SG 135 with the current firmware version.
Two identical cable connections from Vodafone Kabel Deutschland with 1 Gbit each on ETH1 and ETH2 are configured identically on the UTM. Both lines have a static IP that is assigned by the provider via DHCP. Line one has been running smoothly for almost two years. Now a second line has been added, it always runs for about 30 minutes, then it is gone for about 30 minutes. In the log file I see that after the lease has expired, the UTM tries to re-establish the connection. She tries that for about 30 minutes, after which it works again. The uplink balancing is also correctly switched on. Both interfaces are configured as standard gateways.
I have already swapped different Internet interfaces on the UTM, no improvement. In the log file I see the following:
reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2020:12:22-19:29:09 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:29:30 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:29:41 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:30:00 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:30:01 gw /usr/sbin/cron[23544]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2020:12:22-19:30:01 gw /usr/sbin/cron[23545]: (root) CMD ( /usr/local/bin/reporter/system-reporter.pl)
2020:12:22-19:30:01 gw /usr/sbin/cron[23546]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2020:12:22-19:30:01 gw /usr/sbin/cron[23547]: (root) CMD ( /usr/local/bin/rpmdb_backup )
2020:12:22-19:30:17 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:30:30 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:30:44 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:31:01 gw /usr/sbin/cron[24101]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2020:12:22-19:31:02 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:31:19 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:31:27 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:31:35 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:31:47 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:32:01 gw /usr/sbin/cron[24563]: (root) CMD ( nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2020:12:22-19:32:01 gw /usr/sbin/cron[24564]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2020:12:22-19:32:06 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:32:14 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:32:34 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:32:43 gw dhclient: DHCPREQUEST for 24.134.95.205 on eth1 to 88.134.230.2 port 67
2020:12:22-19:32:43 gw dhclient: DHCPACK of 24.134.95.205 from 88.134.230.2
2020:12:22-19:32:43 gw dhclient: bound to 24.134.95.205 -- renewal in 1228 seconds.
2020:12:22-19:32:48 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:33:01 gw /usr/sbin/cron[25076]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/null)
2020:12:22-19:33:08 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 255.255.255.255 port 67
2020:12:22-19:33:17 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 255.255.255.255 port 67
2020:12:22-19:33:26 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 255.255.255.255 port 67
2020:12:22-19:33:26 gw dhclient: DHCPACK of 24.134.237.101 from 88.134.230.2
2020:12:22-19:33:26 gw dhclient: bound to 24.134.237.101 -- renewal in 1554 seconds.
Then after a while this comes up:
19:32:06 gw dhclient: DHCPREQUEST for 24.134.237.101 on eth2 to 88.134.230.2 port 67
2020:12:22-19:34:01 gw /usr/sbin/cron[25630]: (dehydrated) CMD (/var/chroot-reverseproxy/usr/dehydrated/bin/renew_certificate.pl > /dev/n
I have no idea what else to try.
Any help is very welcome.
Cheers,
Horst
OK, after escalation and some investigation from L2 Support and global escalation Team the solution was pretty simple:
NUTM-11005
Sophos Support from Karlsruhe fixed my problem.
Hi H_Patel ,
thanks for the answer.
Here are my ansers:
What is the firmware version on your firewall?
Firmware is 9.705-3
Did you define the gateway for the new WAN interface on the UTM?
Yes, see attachments. WAN1 & WAN2 are from the same Provider and are identical configured. WAN2 ist the one who disconnect ever 30 minutes.
If UTM is sending DHCP requests and does not get DHCP Ack from the server, it needs to be looked at at the upstream device.
I opend several tickets at the provider. He told me everthing is OK on his side :-(
Thanks for helping me.
WAN1:
WAN2
Hello Horst,
why don‘t you just use a static definition, if you know your static ip settings?
Mit freundlichem Gruß, Regards from Germany,
Philipp Rusch
New Vision GmbH, GermanySophos Silver-Partner
If a post solves your question please use the 'Verify Answer' button.
Hallo Horst,
I think we all agree that this is a problem on the Vodafone side that you cannot solve.
You don't seem like the kind of guy that would have done anything to make the Vodafone guy so obstinate. I would ask the Vodafone technician for his name and if he's willing to bet his job that he's right and we're all wrong. I would then call Vodafone sales and tell them you're not getting acceptable support from the guy and that you will switch to DT if they don't get a smarter, more diligent technician on your case.
Cheers - Bob
Hi Bob,
lookslike its a Sophos Problem.... Vodafone cloesed the call without any solution :-( but.... I installed a PFSENSE and made the same config as with the UTM1 35 ( both interfaceset set as DHCP) and guess what ??? Both interfaces stay online since more the 24 hours.
But this is not a solution for me. I want to use both lines on the SG135, otherwise I have double NAT and all the problems with certificates and so on.
If it's what I now think it is, I can't believe that Vodafone is unaware of it. The SGs aren't the only devices that use those Ethernet NICs - not the only ones that might have problems agreeing on speed & duplex with the Vodafone equipment..
Search here and you'll see similar problems with Cisco fibre routers connected to UTMs. The solution was #7.7 in Rulz (last updated 2020-11-12). Any luck with that?
yes, that was one of the first things I tried. I am tired of testing. Really strange ting is, a normal cheap firewall PC from Amazon with PFSENCE installed work as desigend. But as I wrote, thats not a solution.
Darn! What does Sophos Support say about this?
Sophos Support is the next disappointment for me. I opened a ticket there 10 days ago, asked twice - no answer. I wonder why I still buy Sophos UTM at all? I should slowly look around for alternatives.
Hi Applehorsti,
We apologize for any inconvenience you have experienced. Please provide your support case number via PM, and I will help with the follow-up.
Thanks,
Community Support Engineer | Sophos Technical SupportSupport Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts If a post solves your question use the 'Verify Answer' button.
done.
...and 24 hours later nothing happens....
It looks like that was supposed to be fixed in 9.701, Horst. Are you saying that it re-appeared in 9.705?
Cheers - bob
It was fixed in 9.701, thats correct. But....you have to enable this feature manuell, otherwise you run exact in that problem we run.....
Regards,
Hi Horst, need this to be enabled by CLI? And how?
thank you,
Michael