Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Nickel

Anti-spoofing on external interface

Jump to solution

Hi

We have a VSX cluster with a VS for Remote Access. Since our staff now work from home, there is a requirement to allow support staff to use SCCM Remote Control. This is set to connect from an office PC or server out to a Remote Access VPN user. 

After trying various things to get this to work, as a last resort I disabled anti-spoofing on the external interface. Once done, RC worked absolutely fine. 

Leaving this makes me nervous as everything I know says to always have anti-spoofing enabled. So, does disabling it on one interface potentially open us up to more issues? 

Thanks
Roy

 

0 Kudos
1 Solution

Accepted Solutions

Hi @Roy_Smith 

I think it's R80.30. I could see these problems with several other gateways. Here the TAC is also involved.

1) Are your office mode addresses of IP spoofing used for internal interfaces? This may also cause this error.

2) Is IP spoofing active for the office mode pool?

case1.JPG

3) Or set don't check packets from:

case2.JPG

Emergency solution:

From my point of view, change to detect mode of IP spoofing on the external interface is not very security relevant.

Why! All internet IP addresses are allowed here. Private addresses 10.x.x.x, 192.168.x.x, ... are not routed in the internet. If you now drop IP addresses from 224.0.0.0-255.255.255.254, you are reasonably safe. But keep in mind that you have to activate certain multicast IPs (for example HSRP, VRRP,...). But you should also allow 255.255.255.255 in individual cases.

I think the solution is not nice, but you can live with it.

Then you can analyze the issues. The goal should be to enable IP spoofing again.

View solution in original post

4 Replies
Highlighted
Have you tried to add the network you need to connect to externally in the box 'Don't check packets from'?
Regards, Maarten
0 Kudos
Highlighted
Nickel

Maarten

Yes, I have tried putting the VPN subnets in the box and I also tried the internal subnets the VPN clients try to connect with no success. I have messed about with various settings in our anti-spoofing group and encryption domain, again with no success. 

Roy

0 Kudos

Hi @Roy_Smith 

I think it's R80.30. I could see these problems with several other gateways. Here the TAC is also involved.

1) Are your office mode addresses of IP spoofing used for internal interfaces? This may also cause this error.

2) Is IP spoofing active for the office mode pool?

case1.JPG

3) Or set don't check packets from:

case2.JPG

Emergency solution:

From my point of view, change to detect mode of IP spoofing on the external interface is not very security relevant.

Why! All internet IP addresses are allowed here. Private addresses 10.x.x.x, 192.168.x.x, ... are not routed in the internet. If you now drop IP addresses from 224.0.0.0-255.255.255.254, you are reasonably safe. But keep in mind that you have to activate certain multicast IPs (for example HSRP, VRRP,...). But you should also allow 255.255.255.255 in individual cases.

I think the solution is not nice, but you can live with it.

Then you can analyze the issues. The goal should be to enable IP spoofing again.

View solution in original post

Highlighted
Nickel

@HeikoAnkenbrand 

Your screenshots helped a lot. It turned out that "Perform anti-spoofing on Office Mode addresses" was enabled. I disabled this and re-enabled "Perform anti-spoofing" on the interface and everything works as we want. 

Much happier situation now with anti-spoofing enabled again

Thanks for the help
Roy