Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 1985 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

[UTM 9.0000-8] Random timeouts when connecting via L2TP/IPSec?

Astaro Commando
Ever since I loaded UTM9, I've been having sporatic issues with connecting to my UTM9 server via VPN. Sometimes it connects fine, sometimes I will get a timed out error.

A current "patch" is for me to VPN into another location I have access to and then VPN to my UTM9 server. Works fine. Because of this, it looks like it is a source IP address/Location issue. The UTM9 server is simply rejecting connections from certain places. I do have country blocking enabled - but not for the USA.

Any ideas?

Will post the LiveLog output in a bit


This thread was automatically locked due to age.
Parents
  • 0
    Now that I think of it, the problem in the OP might be related to the fact that a client VPN that has this problem is usually on a network that has a 192.168.1.x address. By routing my traffic though my SF VPN server, the IP address is 10.246.x.x

    I think you got it.  In general, the "stock" VPN Pools should be used for the various Remote Access methods.

    In specific, don't have the same DHCP server in use for VPN users as for internal users.  When internal devices try to respond to IPs in their local subnet, they broadcast an ARP request to see which local MAC address they should talk to - the remote client isn't in the internal Ethernet network, so there's no response to the ARP request and the device gives up.  If the IP is not in the local subnet, the device knows to send its message to the MAC address of its default gateway.

    If you were having problems reaching internal devices, there's another potential "gotcha" in Network/Host definitions.  Check to be sure that none are bound to a specific interface and that each one has been left at 'Interface: >'.

    Cheers - Bob
Reply
  • 0
    Now that I think of it, the problem in the OP might be related to the fact that a client VPN that has this problem is usually on a network that has a 192.168.1.x address. By routing my traffic though my SF VPN server, the IP address is 10.246.x.x

    I think you got it.  In general, the "stock" VPN Pools should be used for the various Remote Access methods.

    In specific, don't have the same DHCP server in use for VPN users as for internal users.  When internal devices try to respond to IPs in their local subnet, they broadcast an ARP request to see which local MAC address they should talk to - the remote client isn't in the internal Ethernet network, so there's no response to the ARP request and the device gives up.  If the IP is not in the local subnet, the device knows to send its message to the MAC address of its default gateway.

    If you were having problems reaching internal devices, there's another potential "gotcha" in Network/Host definitions.  Check to be sure that none are bound to a specific interface and that each one has been left at 'Interface: >'.

    Cheers - Bob
Children
No Data