A funny thing I learned today about Check Point. Here is the scenario: I have a remote-access client wanting to vpn into my check point clustered environment. Im running R75.20. Remote-access works great. I can get to everything, except I can not get my Avaya softclient to register to the IPT server inside the network from across the remote-access vpn. I start the client up, and try to log in, and it times out. Seems really odd, since I CAN ping this server and telnet to it. So, routing is out. No route-maps in the network that would send protocol specific traffic elsewhere. What gives? First, know that I had a rule specifying that vpn users could get to anything, with any service allowed. The IPT server was in the encryption domain as well. Everything looks good in the config.
So, I call Check Point TAC up, and after some time in looking at this, they tell me to add another rule specifically allowing the H323 traffic Im trying to get across with the Avaya client. I tell them I have a rule already allowing "any" traffic through. Essentially, they tell me to just do it. So, I did add a rule in to allow H323 traffic through and back. I saved and pushed policy and it the Avaya client worked. Hmmm. I have no idea why this worked. But, I did. I had another guy tell me at this customer site that he has seen this sort of thing before. When I ask why, his answer was "Its check point."
So, this got fixed by adding another rule in the rule base for a protocol (H323) that was already allowed anyway. This is one of those scenarios where I just have to shake my head and say "I dont know."
No comments:
Post a Comment
Your comment will be reviewed for approval. Thank you for submitting your comments.