Secureclient failed to communicate with Policy Server xxxx at site xxxx?

[Spacetrucker]

I have a Secure Knowledge document SK 24924 that says I need a routing entry on the gateway for OM.

Cause:The routing entry for IP addresses allocated by OM on the Security gateway/policy server points to a gateway other than the next hop router on its external interface side.
Solution: Corrrect the routing table on the Security gateway. Change that route to point to the router, which is the next hop.

I didn't have a route for OM setup so I added one and I'm asking if I've got it right? This is my routing entry.

192.168.112.0 --- 0.0.0.0 --- eth0

[RayPesek]

Where does the default route on the firewall point?

Ray

[Spacetrucker]

Not sure,check me if I'm wrong, it's eth0 on the firewall.
Public subnet x.xx.133.64/25
x.xx.133.64 is assigned to eth0 on the router.
x.xx.133.65 is assigned to eth0 on the firewall.
Netstat -rn on the firewall returns.

Dest-----------Gateway------------General Mask--------Flags---Interface
x.xx.133.64----0.0.0.0--------------255.255.255.192----U-------eth0
192.168.112.0-0.0.0.0--------------255.255.255.0-------U-------eth0
0.0.0.0--------x.xx.133.65----------0.0.0.0--------------U-------eth0

[mcnallym]

Normally you should not need a route on the Gateway to get Office Mode to work.

What it normally refers to is if your SecureClient Gateway is not the Default Gateway for your Network, then you need to add a route to the network equipment to route the office mode network back to the SecureClient Gateway.

ie if you have your main firewall is 10.10.10.10 and you have a VPN gateway that is 10.10.10.11 then your internal network would need to route the Office Mode network back to 10.10.10.11 as otherwise would end up at the 10.10.10.10 box by default.

[Spacetrucker]

Originally Posted by mcnallym

Normally you should not need a route on the Gateway to get Office Mode to work.


What it normally refers to is if your SecureClient Gateway is not the Default Gateway for your Network, then you need to add a route to the network equipment to route the office mode network back to the SecureClient Gateway.

>>We have a very simple setup, just clients connecting back to one gateway in front of one network. So I'm guessing that the default gateway is the SC gateway.

ie if you have your main firewall is 10.10.10.10 and you have a VPN gateway that is 10.10.10.11 then your internal network would need to route the Office Mode network back to 10.10.10.11 as otherwise would end up at the 10.10.10.10 box by default.

Would you mind confirming what my default gateway is based on what I've posted?

[melipla]

Originally Posted by Spacetrucker

Would you mind confirming what my default gateway is based on what I've posted?

You've given us conflicting information so its hard to tell what your default gateway is. Let me explain.

x.xx.133.64 with a mask of 255.255.255.192 means that .64 is the network address, you can't assign this IP to a device. You say that x.xx.133.65 is your firewall, but you're using 133.65 as your firewall's default gateway. I'm guessing that x.xx.133.65 is really your router and that if you did an "ifconfig eth0" you'd see a different IP listed on your firewall.

Going back to your original question, having this entry in your netstat output:
192.168.112.0-0.0.0.0--------------255.255.255.0-------U-------eth0
Would mean that its a "directly connected" interface. As in, an ip in 192.168.112.0/24 is set up on eth0. This entry in your netstat output:
x.xx.133.64----0.0.0.0--------------255.255.255.192----U-------eth0
Also means that an ip in xxx.xxx.133.64/26 is set up on eth0 which indicates a possible conflict as to what eth0 is really set up as. An "ifconfig eth0" should clear this up, however it is possible to have a secondary address on eth0 but that's uncommon & not recommended.

Did you add in the route for 192.168.112.0 yourself? How exactly did you add it?

To clear up what the SK is talking about, you only need to add a route IF you have secureclient users connecting to your gateway from interfaces which are not your default interface [typically eth0]. For example, if you do a traceroute from your SecureClient, which firewall interface will it reach first--is it eth0? If so then you do not need to add any routes for SecureClient traffic to work.

If your SecureClient traffic can reach the firewall from two different interfaces, meaning users at home connect through eth0 and users at your office using wireless connect through eth1 then let us know.

[MarioL]

.64 is actually a network address and with .192 netmask it's BC is .127, leaving 65-126 as "available" IPs.

[Spacetrucker]

Originally Posted by melipla

You've given us conflicting information so its hard to tell what your default gateway is. Let me explain.

Sorry about that, don't mean to.

Originally Posted by melipla

x.xx.133.64 with a mask of 255.255.255.192 means that .64 is the broadcast address, you can't assign this IP to a device. You say that x.xx.133.65 is your firewall, but you're using 133.65 as your firewall's default gateway. I'm guessing that x.xx.133.65 is really your router and that if you did an "ifconfig eth0" you'd see a different IP listed on your firewall.

You guessed right, ifconfig eth0 returns x.xx.133.66. I'm not sure of what's on the router because an outside vendor manages it, we own it, and they won't provide me with a copy of the router config. So I'm guessing when I say x.xx.133.64, it may well be x.xx.133.65.

Originally Posted by melipla

Going back to your original question, having this entry in your netstat output:
192.168.112.0-0.0.0.0--------------255.255.255.0-------U-------eth0
Would mean that its a "directly connected" interface. As in, an ip in 192.168.112.0/24 is set up on eth0. This entry in your netstat output:
x.xx.133.64----0.0.0.0--------------255.255.255.192----U-------eth0
Also means that an ip in xxx.xxx.133.64/26 is set up on eth0 which indicates a possible conflict as to what eth0 is really set up as. An "ifconfig eth0" should clear this up, however it is possible to have a secondary address on eth0 but that's uncommon & not recommended.

Did you add in the route for 192.168.112.0 yourself? How exactly did you add it?

I used the sysconfig utility. And, I don't have an ip address from 192.168.112.0 set up on eth0. I checked the topology on the gateway object, and ifconfig. Anywhere else I should look?

Originally Posted by melipla

To clear up what the SK is talking about, you only need to add a route IF you have secureclient users connecting to your gateway from interfaces which are not your default interface [typically eth0]. For example, if you do a traceroute from your SecureClient, which firewall interface will it reach first--is it eth0? If so then you do not need to add any routes for SecureClient traffic to work.

Yes, SC will hit eth0 first, I'm still getting the msg, so I deleted the route using sysconfig, adding the route isn't solving the problem.

Originally Posted by melipla

If your SecureClient traffic can reach the firewall from two different interfaces, meaning users at home connect through eth0 and users at your office using wireless connect through eth1 then let us know.

To the best of my knowledge everyone connects via eth0. We don't have users connecting to the private network via wireless at the moment.

[melipla]

Originally Posted by Spacetrucker

I used the sysconfig utility. And, I don't have an ip address from 192.168.112.0 set up on eth0. I checked the topology on the gateway object, and ifconfig. Anywhere else I should look?

Removing the old route which you said you did below is a good first step as it was a bad route. If you do a netstat -rn you should no longer have this entry, correct?
192.168.112.0-0.0.0.0--------------255.255.255.0-------U-------eth0

Originally Posted by Spacetrucker

Yes, SC will hit eth0 first, I'm still getting the msg, so I deleted the route using sysconfig, adding the route isn't solving the problem.

Given the information so far, its fair to say that SK does not apply to you. Now I'm not positive on what your problem is, can you give a description?

[Spacetrucker]

Originally Posted by melipla

Removing the old route which you said you did below is a good first step as it was a bad route. If you do a netstat -rn you should no longer have this entry, correct?
192.168.112.0-0.0.0.0--------------255.255.255.0-------U-------eth0?

That is correct, the routing entry is gone.

Originally Posted by melipla

Given the information so far, its fair to say that SK does not apply to you. Now I'm not positive on what your problem is, can you give a description?

I'm getting the msg 'Secureclient failed to communicate with the Policy Server <ServerName> at site <SiteName>'. This happens at random on different laptops, it's not consistent, and we can connect and receive an OM address.
I thought that by adding the route I could eliminate the msg, period.

My real question\problem has become "what is my default route\gateway on the firewall?"

I'm trying to answer Ray's question of "Where does the default route on the firewall point?"

I thought one could tell from the output of netstat -rn on the firewall.

[melipla]

Originally Posted by Spacetrucker

My real question\problem has become "what is my default route\gateway on the firewall?"

I'm trying to answer Ray's question of "Where does the default route on the firewall point?"

Your default route points to xxx.xxx.133.65. Assuming you don't have any other routes which would encompass 192.168.112.x, this means that the firewall routes anything destined for 192.168.112.x out to xxx.xxx.133.65 (because it would match the default route).

Originally Posted by Spacetrucker

I'm getting the msg 'Secureclient failed to communicate with the Policy Server <ServerName> at site <SiteName>'. This happens at random on different laptops, it's not consistent, and we can connect and receive an OM address. I thought that by adding the route I could eliminate the msg, period.

I've had similar problems with policy server communication. Is the gateway they're connecting to the same gateway that is the policy server?

In SmartDashboard under properties for the gateway object -> Remote Access -> Office Mode, do you have "Support connectivity enhancement for gateways with multiple external interfaces" selected?

Do you see any Anti-spoofing or drops related to policy server in Tracker / SecureClient logs?

[Spacetrucker]

Originally Posted by melipla

Your default route points to xxx.xxx.133.65. Assuming you don't have any other routes which would encompass 192.168.112.x, this means that the firewall routes anything destined for 192.168.112.x out to xxx.xxx.133.65 (because it would match the default route).

Thanks for confirming this point.

Originally Posted by melipla

I've had similar problems with policy server communication. Is the gateway they're connecting to the same gateway that is the policy server??

Yes it is, we only have one gateway and everything is on it. It's a SPLAT R60HFA03 gateway.

Originally Posted by melipla

In SmartDashboard under properties for the gateway object -> Remote Access -> Office Mode, do you have "Support connectivity enhancement for gateways with multiple external interfaces" selected?

No, I don't, should it be enabled?

Originally Posted by melipla

Do you see any Anti-spoofing or drops related to policy server in Tracker / SecureClient logs?

I'll need to check. I do have a question about the the SC logs. I see lots of inbound drops, I never see anything inbound that is not dropped. Should I be seeing some inbound traffic that's accepted or encrypted? On outbound I
see encrypt and a few rejects. I've read that all inbound traffic is dropped by default, is this true? I'm guessing that the way it works is that when an outbound packet is encrypted both the inbound and outbound traffic for that particular conversation are contained within that encrypted stream\tunnel between the SC client and the gateway. And, this is why I'm not seeing any inbound traffic that's accepted\encrypted.

[Spacetrucker]

In my SC logs I see the Action-Control for connecting to the site and authenticating the user. A few lines down usually 5, I see Action-Accept, Outbound, Service-netbios-ns, Src-192.168.112.x - Dest-192.168.112.255, Protocol-UDP, S_Port-137. I see the same thing for Port 138 and netbios-dgm.

After the first ones are accepted, all of the others are rejected, I've read ports 135-139 are MS security horrors.

The ones rejected are using this outbound rule, which comes before the rule that accepts them.
SC_Users@any - MySubnets - any - encrypt - alert

The ones that are accepted, are accepted using this outbound rule.
Allusers@any - any - any - accept - alert

Why would these be rejected after the first two are accepted? Is there an implied rule coming into play here?

[melipla]

Are there different rules matched on the drop? As far as I know there is no implied drop possible for desktop policy, unless you're using the default drop policy (which it sounds like you're not). I don't think I'd be too concerned about these broadcast drops.

Troubleshooting policy server connections can be difficult. If its a new client install, then try to have them connect to the gateway and then go into their VPN settings and update the site manually.

Another thing I've noticed is that occasionally a client will attempt to retrieve policy from the non-external IP of the gateway. Filter traffic based on tcp/18231 in SmartView Tracker and see if the client request are making it through. Depending on your timeout period (found under global props under RA) should tell you how often you'll see the requests.

You could also try to use srfw monitor (securemote fw) and fw monitor to see if the client is initiating the request for a policy as its supposed to (i'd recommend trying to capture this during the login process when the policy is expired). If the client isn't requesting it properly then maybe you should try installing a supplement version of secureclient that Check Point creates just for you..... ;)

[Spacetrucker]

Thanks Melipla, my CIO and our #1 honcho are both overseas and using the vpn successfully, so I think their concerns have been put to rest.

My CIO was asking me to explain why he only saw drops on the inbound connection, and never any accepts, and the rejects, rather than encrypts on the broadcast traffic. I was trying to come up with an answer for him.

I also have several other users who travel overseas frequently, and some scattered across the states who use the vpn everyday and rarely have problems. Let it be the top honchos who have a problem, and you go under the microscope and each item has to be explained in detail. Many thanks to you and everyone else who pitched in here. I think we can put this one to rest for now.

[RayPesek]

Can you explain in a bit more detail what he saw and what he thinks he should see?

A remote access client shouldn't ever see any Accepts when off the company LAN. If it did, it would mean something on the remote access computer is running a server or is infected with malware that is listening for inbound connections. It also should not accept broadcasts because nothing should be trying to find the remote access computer by broadcast.

Ray

[Spacetrucker]

Originally Posted by RayPesek

Can you explain in a bit more detail what he saw and what he thinks he should see?

A remote access client shouldn't ever see any Accepts when off the company LAN. If it did, it would mean something on the remote access computer is running a server or is infected with malware that is listening for inbound connections. It also should not accept broadcasts because nothing should be trying to find the remote access computer by broadcast.

Ray

Ray - are you saying the client should'nt ever see any Inbound Accepts or any Accepts period?

[RayPesek]

When off the LAN, yes. Remember that an inbound ACCEPT is log entry for an unencrypted initial connection from the outside, just like on a FW-1.

On the company LAN, I would expect to see inbound ACCEPTs for network monitoring systems, patching systems like SMS, and "you've got new email" connections from Exchange to Outlook.

Off the LAN and when not connected by VPN, an inbound ACCEPT most likely is someone scanning the computer or attempting an intrusion. Your desktop security rules for "all users@any" should be blocking these, and it sounds like it is.

Ray