- CheckMates
- :
- Products
- :
- Quantum
- :
- Remote Access VPN
- :
- Re: Internal Servers cant access after login the c...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Internal Servers cant access after login the client
Hi Checkmates,
I have created tasks that Remote access VPN client users login to the checkpoint VPN client.
VPN users can login to the VPN client and can get the IP pool with DNS.
After login successfully into the VPN client, the can't access the internal servers. Please any help.
1. I have created rule that matches
Source : Access role (Local users, network vpn Pool IP address),
Destination: Local LAN network, servers
RemoteAccess VPN community enabled.
2. OSPF is enabled between CP firewall and internal LAN switch
3. Static routing to external
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey @AkosBakos
I did remote with @yeruel and after checking all the basic settings first (such as IA blade remote access option, OM mode, access role, tested with subnet instead), we checked topology for eth2, which was interface involved and realized that 10.1.0.0/16 subnet was missing, so once we created new group and added 172.20.10.0/24, 172.20.27.0/24 and 10.1.0.0/16 into it, assigned to eth2, pushed policy, all worked fine, no issues, we could ping without even having to reconnect the client.
All these small things, hehe 🙂
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. Any drops logs for the traffic flow and what do you see with tcpdump / debugs?
2. What gateway version/JHF and which VPN client version/build?
3. Is it DNS related or does even basic connectivity by IP not work?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- The vpn client is R81.20 downloaded https://support.checkpoint.com/results/download/95064
- Gateway version is R81.20
- Drop with the cleanup rule. It doesn't matches the remote access VPN rule.
The rule name VPN rule
Source: access role (name is VPN-remote-access) which contains network pool for VPN client 192.168.253.0/24, and users - local users)
Destination: Local network and servers
VPN: RemoteAccess
Service : any/ allow
There is ospf routing to the internal network, that's full established.
The issue is after successful login to the VPN client, users can't access internal network.
Do you think my rule match is correct? The source: is that possible to use access role?
Note: the source policy is Unified
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please note E88.x is the current client version, E81.20 is end-of-life
Regarding the access role, do you have identity awareness enabled with the remote access identity source selected?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will change the VPN client version. and regarding the Identity awarness, yes it has been enabled, and also AD users are login to the Client-less SSLVPN portal for web application access. Every AD users are loggining and accessing the web application servers. The issues is for the client vpn users after login to access internal server. For Clientless, users are accessing the web servers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had that sort of situation happen before with customers and here is BEST way (at least best I found) to make sure if its identity awareness /access role issue. All you do is replace access role as src with say network group, install policy and test. If that works, then you know 100% what is the issue.
Hope that helps.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @the_rock
There is new thing, VPN client users with local users after successful connected to VPN, users can access some servers (172.20.10.10, 172.24.2.3 and subnet of 172.24.x.x and 172.20.X.X), but for others 172.17.0.0 and 10.1.0.x network can't access. The policy for VPN rule is the same single rule.
Source: access role, destination: 172.24.x.x, 172.17.x.x, 172.20.x.x and 10.1.0.x), VPN: remote access, service any any.
Why 172.17.x.x, 10.1.0x are not accessible? Can you provide best solution?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We would need to see why it fails...as @Chris_Atkinson asked in the beginning, any relevant logs indicating the reason?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey @yeruel
Just thought of something else you can do as a test. Change topology as below and see if that works after pushing the policy.
Andy
-
Network defined by routes - The gateway dynamically calculates the topology behind this interface. If the network changes, there is no need to click "Get Interfaces" and install a policy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you send screenshots of the drop and the rule which should handle the traffic?
A screenshot would be great, where we can see a successful login in Identity Awareness.
And what is the IP that is received the client from the gateway when the VPN client connects?
Akos
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @AkosBakos
Attached screenshoot,
1. VPN client users from internet can login using the local users name and connected to the site
2. VPN Pool IP recevied from vpn pool ip 192.168.254.0,
3. Try to access the internal servers from application servers area. Application servers area network is accessiable
4. Server storage and server farm network are not accissiable from vpn client.
5. From Server storage and server farm (10.1.0.0 and 172.17.0.0 to the outside internet 8.8.8.8 is working fine)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
In Access rule 1, the Remote Access community intentionally not set in the VPN column?
And the most trivial question, but I want to ask: in the VPN-POOL object the subnet mask is configured corretly (or the network)?
Akos
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
attached to address your question.
I just tried to add vpn remoteaccess to rule 1, no result.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you do route print from cmd on client PC (one of them) that does not work and compare it with same command on one that does work?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wait, this is not a simple drop:
"Encryption Failure: according to the policy the packet should not have been decrypted"
Someting is not overlapping?
https://support.checkpoint.com/results/sk/sk64060
Akos
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was just about to give that sk as well. To me, that more seems related to S2S vpn.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any one who can assist via virtual meeting, please
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yea, lets do zoom, message me directly.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please update me with the findigs 🙂
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey @AkosBakos
I did remote with @yeruel and after checking all the basic settings first (such as IA blade remote access option, OM mode, access role, tested with subnet instead), we checked topology for eth2, which was interface involved and realized that 10.1.0.0/16 subnet was missing, so once we created new group and added 172.20.10.0/24, 172.20.27.0/24 and 10.1.0.0/16 into it, assigned to eth2, pushed policy, all worked fine, no issues, we could ping without even having to reconnect the client.
All these small things, hehe 🙂
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
you mean that, one network was missing from the AntiSpoofing group (Topology)
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yup!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
WOW! You are very nice! everything is fine now!
You deserved 5 stars!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think that's for site to site VPN, I am not going to do S2S VPN. My scope is Remote access from the internet using vpn client.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I know, but something can overlap with the Remote Access IP range
\m/_(>_<)_\m/