Need to masquerade for SSL VPN

Please show a pic of your 'Remote Access >> SSL' 'Global' tab.  Also of the related packet filter rules if you aren't using 'Automatic packet filter rules'.

On the global tab the following is specified:

users and groups:

only one account, my account

local networks:

internal network (network)

Automatic packet filter rules is checked.

Franc.

Oops, Bob you're right.

Barry

Franc, you'd need Masq if you want VPN to access the internet.
But for VPN - LAN, it doesn't matter.
Check your packetfilter log and see if you see any drops from the VPN.
Also check the ICMP settings under PacketFilter-ICMP, and then try Ping and/or Traceroute from VPN to LAN.

Barry

Hi,

disabling the MASQ rule has the following effect:

Pinging 10.1.2.81 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.1.2.81:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


tracert 10.1.2.81

Tracing route to 10.1.2.81 over a maximum of 30 hops

  1    13 ms    14 ms    12 ms  10.242.2.1
  2     *        *        *     Request timed out.


Packetfilter doesn't show any dropped packets.

Franc.

What settings do you have on the 'ICMP' tab of 'Network Security >> Packet Filter'?

Allow ICMP on firewall : checked
Allow ICMP through firewall: checked
Log ICMP redirects: unchecked

Firewall is ping visible: checked
ping from firewall: checked
firewall forwards pings: checked

Firewall is traceroute visible: checked
Traceroute from firewall: checked
Firewall forwards traceroute: checked

Franc.

This just doesn't make sense.  I know you told us what's on the 'Global' tab of SSL, but the only thing I can think of is to ask again for a picture of that.  It sounds like everything is right.

Hi Bob,

I know, I don't get it either ;-) When I start a ping -t  I get a reply, when I disbale the MASQ rule I immediately receive request time out...

See attachments.

Franc.

Franc, do you have any other NAT or Masq settings which could be interfering?
Any policy routes?

Barry

Hi Bob,

no I don't. The only MASQ rules I've set are from the host in the DMZ to External, Firewall on Internal network to External and VPN Pool (ssl) -> Internal

No packet filter rules regarding the SSL VPN

Franc.

Very strange.  What about your SNAT and DNAT rules?

Very strange.  What about your SNAT and DNAT rules?

Hi Bob,

I've sent the screenshots of my DNAT/SNAT rules to you by private message if you don't mind.

Edit: hmmm, it seems I'm not able to send attachments using private messages.

Franc.

Yes, received the email.  Everyone, I can't see anything in his 11 DNATs that would hi-jack ping traffic - or anything else for that matter.

I don't understand.  It seems like it's not getting the routing.  At this point the only thing I can think of is to completely uninstall the SSL client, then re-install from the User Portal.  Something didn't "take" the first time.

Cheers - Bob

Hi Bob,

thanks. But is there some explanation that everything works fine when I enable the masquerading rule? When everything is OK once the MASQ rule is active then it couldn't be the client, could it ?

Franc.

Do you have the Local networks correctly defined in the VPN setup on the firewall?

Barry

The screenshot of the global settings tab some posts earlier show that I have.

Franc.

Hi there, 

in order to make sure that this setup works, you have to make sure, that the computer/server in the LAN to which you want to connect to, routes all traffic going to '10.242.2.0/24' need to be sent back to the Astaro Gateway. 

This is normally done by setting the default gateway to the Astaro, but i have seen scenarios in the past, where ASG has been used as a VPN gateway and the default firewall was another system. 

That would also explain why the setup works if Masquerading gets enabled, because in this case, the SRC ip gets substituted with the Interface IP of the ASG from '10.1.0.0/16'. As this ip address is directly addressable from the computer/server, it will be routed back to the ASG.

THere are two solutions:
1) change the default gateway to Astaro
2) add a route to the computer/server you want to connect from the VPN, and route the network '10.242.2.0/24' to the ip adress of the ASG. 

this should than hopefully fix the problem. 
Does it?

regards
Gert

Hi Gert,

that's indeed our setup. I use the ASL with 2 internal nics (see my first post), one is connected to the internal network directly (bypassing our proxy server whcih sits between the internal network and the dmz) and the other is connected to one side of the DMZ. Now you mention it, the default gateway for our internal hosts isn't set to the ASL but to the other firewall. Your explanation makes full sense to me now. Thanks! 

Bob and Barry, thanks for all your help and sorry if my answers weren't clear enough to state that I was using the setup Gert describes. I sincerely apologize for that!

Franc.

I'm glad that, once in a while, we give Gert an opportunity to work on an interesting problem here! [;)]

So, it wasn't that the ping wasn't getting to the server, it was that the server didn't have a route back to the pinger.  Once again, it's amazing how simple an answer seems when you find it.

Thanks for posting the problem Franc, and being so diligent in working through the meanderings of the rest of us.

Cheers - Bob

Hi Bob,

no problem, we are all here to help and solve issues so that other people can learn from it.

Franc.

I have a final question.
Any impact on using Masquerading vs. Routing? Performance? Other?
I need a working solution and now I have two :-)

I face the same situation (Internal host's default gateway is different from the Astaro's server) and have to decide if I leave Masquerading on, or take it off and use regular routing.

Instead of adding a route on each host, I would add the route once on the default gateway router to send back the corresponding traffic to the Astaro Gateway though.