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

VPN client - can't ping internal network

ntomsheck
Hey guys,
I know this issue has been beaten to death, but in all the threads I've searched, there is either no resolution posted, or I have tried all of the tests/checks suggested.
Using a home user firewall license, 8.102

I've set the VPN client up for other clients, but can not seem to get it to work on my network.  The client laptop is on a 192.168.2.x network, using default VPN pool addresses.

The client connects, and I can ping the astaro gateway (10.0.0.1), but can not ping any of my servers (10.0.0.10+) or any other devices on my network.  Web servers are nix based, so it's not a windows firewall issue.

I've looked at the packet filter log, and it shows nothing related to the vpn. The remote access settings are correct from what I can tell - my username allowed, to internal networks (10.0.0.x).  No WINS, DNS settings are set correctly, but I can handle DNS issues once I figure out the more important issues.  Made sure the auto-packet filter rule box was checked, etc.

Thank you for reading through this


This thread was automatically locked due to age.
  • 0 in reply to BAlfson
    What is the default gateway for the devices in .x.0/24?

    Cheers - Bob


    The default gateway is set by the dhcp server and is .x.1 (ASG internal address) on each respective network.  The only static mapped device on either network has the default gateway set to .x.1 also.

    The traffic appears to be getting to the distant end ASG but I cannot find any logs showing that the traffic that is supposed to be going through to the internal network is being dropped.
  • 0
    Is there anything unusual in the Intrusion Prevention log?

    Maybe it's time to take a look at the traffic on the remote internal interface with tcpdump from the Astaro command line.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Is there anything unusual in the Intrusion Prevention log?

    Maybe it's time to take a look at the traffic on the remote internal interface with tcpdump from the Astaro command line.

    Cheers - Bob


    IPS isn't showing anything at all.  Completely empty logs on both ASGs.  I'll have to give tcpdump a try and dig around a bit.

    Thanks for the help.  I'll let you know what tcpdump turns up.
  • 0 in reply to Tetz
    Are you running Windows 7?  Is UAC enabled?  If so, exit the ssl versions that starts with your profile, and right click and choose: Run As Administrator.  See if it works then.  I was having a very similar problem.  It turned out that the routes were not getting added (showed as error in the status window of astaro client) to the IP tables because a recent windows update made that an Admin only priveledge.
  • 0 in reply to number2jcb
    Are you running Windows 7?  Is UAC enabled?  If so, exit the ssl versions that starts with your profile, and right click and choose: Run As Administrator.  See if it works then.  I was having a very similar problem.  It turned out that the routes were not getting added (showed as error in the status window of astaro client) to the IP tables because a recent windows update made that an Admin only priveledge.


    It's an ASG to ASG vpn to Windows isn't involved with this one.  BUT, it seems that after the update, the problem appears to be mostly fixed.  At least I can ping a device on the distant end network now.  I'm going to play with tcpdump some more.  Thanks for the help guys.  Sorry it took so long to respond.  Not much time anymore.
  • 0
    I've had PPTP working fine in 8.1. Clients were assigned IP addresses of the internal network to avoid having to set static routes on the client side. Worked fine.

    8.200 broke this. I can tell from the firewall logs that the ASG is now considering this to be IP spoofing (IP addresses from the internal network are coming in through the external network/PPTP). 

    Check your logs, you should see statements like:
    "Spoofed Packet".

    I am not sure how to control IP spoofing on the ASG. If it can't be controled, then the only solution will be to assign IP addresses to the PPTP clients that are not part of any internal network. That also means we will have to set up static routes on the client because last time I checked, the ASG was not able to send the required routes to the client during PPTP negotiation.

    Going to open a ticket for that with support.
  • 0
    WebAdmin>>Network Security>>Firewall>>Advanced Tab.  Turn spoof protection off.

    I believe that this was by design and not a bug.  It's always been considered a bad practice, with any VPN, to use the same addresses as the local LAN.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • 0 in reply to Scott_Klassen
    WebAdmin>>Network Security>>Firewall>>Advanced Tab.  Turn spoof protection off.

    I believe that this was by design and not a bug.  It's always been considered a bad practice, with any VPN, to use the same addresses as the local LAN.


    Of course it's bad practice, but sometimes you don't have alternatives. We tried with a dedicated IP subnet before, but since ASG is unable to conform to RFC standards, e.g. assign proper routing information to clients during PPTP negotiation, we had no choice. Unless we wanted to set static routes on each client PC every time a PPTP session was started.

    Turning IP spoof protection off is obviously not an option either.

    Guess it's time the customer kisses PPTP goodbye and uses IPSec.
  • 0
    Cryptochrome, I don't believe that the Astaro has an inability to assign proper routing, just that there's a misconfiguration.

    Scott, don't you think that the spoofing problem is because he has fixed a misconfiguration with something like a masq rule and is seeing an unintended consequence of that?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    @Balfson:  That's very possible Bob.  I mentioned turning off Spoof protection because there were known issues with it late in the beta and into 8.200 soft-release.  Even in Normal mode, it was acting too aggressively.  This was supposed to be fixed for 8.201, but I hadn't seen it mentioned in the release notes.

    Do you know of an issue with PPTP not sending routes, per his first post?  I don't do PPTP, the least secure VPN method.

    @Chyptochrome:  Per Bob's suggestion, would you care to share your masq rules with us?
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
Unfiltered HTML