Deny IP ADDRESS over VPN

[slispd]

Hello,

I have 3 fortigates connected with vpn.

FGT_A =========== FGT_B ============ FGT_c

Lan FGTA: 192.168.1.0/24

Lan FGTB: 192.168.2.0/24

Lan FGTC: 192.168.3.0/24

The internal network of the fortigate A acesses the internal network of the fortigate C through the fortigate B, however, I can not only block an ip in the fortigate C. I want to completely block ip 192.168.1.10, it should not access the 192.168.3.0/24 network. I create the denying policy on fortigate C, however in the diag sniffer it still traffics by ip-proto-4, how do I only block one ip?

192.168.1.10 -> 192.168.3.200: ip-proto-4 52

192.168.1.10 -> 192.168.3.200: ip-proto-4 88

192.168.1.10 -> 192.168.3.200: ip-proto-4 52

192.168.1.10 -> 192.168.3.200: ip-proto-4 88

192.168.1.10 -> 192.168.3.200: ip-proto-4 52

192.168.1.10 -> 192.168.3.200: ip-proto-4 88

[lobstercreed]

Did you make sure your source interface in the denying policy is the VPN tunnel?  This should work if your policy is set up correctly, so I'm thinking you're missing something there.  Feel free to share more config so I can help you better.

[sw2090]

ok,

first  of all check tow basic things:

a) does FGTA do NAT on the Policy that allows traffic from 192.168.1.0 to 192.168.3.0?

     If it does then FGTC will never ever "see" 192.168.1.10 due to the NAT. If you do need the NAT you would have to       block this on FGTA. IF you do check on b)!

b) check the order of your policies! Policies are handled squentially from top to bottom and the first one that matches your packt will win! So if e.g. the policy that allows traffic from 192.168.1.10 to 192.168.3.0 o FGTC comes before the policy that denies 192.168.1.10 then the denying policy will never ever match any packet because the allow one matches first.

Then to see if you policies work the packet sniffer is not the right tool. It will only show you that your FGT receives or sends packets. So in sniffer you would see packets from 192.168.1.10 on FGTC even if they get blocked.

The best way to check on policies is to monitor the packet flow:

"diag debug enable

 diag debug flow show console enable

 diag debug flow filter <saddr|daddr> <ip>

 diag debug flow trace start <numberofpackets>"

saddr/daddr are the most common filters you need (s(ource)addr(ess) and d(estination)addr(ess))

diag debug flow filter clear will delete all filters.

once you started the trace you need some traffic to occur. The easiest way to do this is to just ping the ip you filtered ;)

Then you will see what policy matched and if it is the right one.

hth

Sebastian