First of all, thanks for your interest in helping!
Initially I also thought about routing, but the pools in the group that has a problem use the same subnet. All others use different subnets. See the print.
Regarding the details of the logs you commented, there is really no answer from the other end.
Hi @Amaro123 ,
I am not sure that using same IP pool for the two different gateways is good (not sure what word to use..) configuration.
I believe I have read somewhere while ago that if you assing same IP pool to two different agent config/user group this could cause IP conflict and firewall can assign the same ip to two different users. FW is monitoring the IP allocation "locally" for each agent config, without being aware of the all the pools configured on the GP gateway. I believe I read this mainly for same ip pool under one gateway, but in my humble opinion it should be a problem with two separate gateways. When you assign IP pool to gateway agent config FW will create static route (or split it to multiple static routes) pointing to the tunnel interface assosiated with gateway. If you assign same IP pool to two different gateways, I assume FW will try to create same static routes pointing to two different tunnel interfaces. Which could explain your issue -fw has static routes for IP pools pointing to tunnle.1 and tunnel.2, when you connect to gateway1 traffic is working as return traffic is taking first route. But when you connect to gateway2 return traffic is routed to wrong tunnel interface and traffic doesn't reach the user.
In any case I really don't like the idea of having same IP pool assigned to more than one gateway agent config (no matter if it is on same gateway or different). I just think FW will have problems with that.
But if you want, before trying with different IP pool, create a packet capture
- listening on the inside interface (the lan behind the fw)
- try connect to gateway2 with problematic group and generate traffic to inside (simple ping will do the trick)
- check the capture - do you see replies hitting the inside interface ( this will confirm that you have bi-directional traffic behind the firewall and that fw is receiving all the traffic, but after that it doesn't route properly or dropping return traffic)
Changing the subnet to a different one had no effect. I had already done this test and the scenario was the same.
And there is no other device for routing connected to the firewall.
Yesterday the firewall was rebooted by a power failure in the rack where it is and I did new tests today. Even if I am not successful in ping or telnet communications, I can see by the details of the logs that there is an answer.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!