Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Roy_Smith
Collaborator
Jump to solution

Anti-spoofing on external interface

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
HeikoAnkenbrand
Champion Champion
Champion

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.

➜ CCSM Elite, CCME, CCTE

View solution in original post

4 Replies
Maarten_Sjouw
Champion
Champion
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
Roy_Smith
Collaborator

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
HeikoAnkenbrand
Champion Champion
Champion

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.

➜ CCSM Elite, CCME, CCTE
Roy_Smith
Collaborator

@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

 

 

 

 

 

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events