| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| I'm using a SPLAT cluster R60 HFA04 and I recently created manual NAT rules similar to the following: src: 10.1.0.0/16 10.2.0.0/16 dst: ANY xlate src: 128.100.100.1(hide) src: 10.3.0.0/16 10.4.0.0/16 dst: ANY xlate src: 128.100.100.2(hide) My connections are all working as expected, but I am getting a lot of 'address spoofing' alerts in my log viewer. If legitimate, traffic from outside heading into my network is logging an ACCEPT connection first on the ingress (external) interface, and then immediately after, logging a DROP on the egress (internal) interface with an address_spoofing comment. Is there any way to resolve this issue? It doesn't appear to be affecting traffic, but it really looks funny in the logs. I have tried creating another manual NAT rule similar to the ones that are created when you check 'Add automatic NAT rules', such as below: src: 10.1.0.0/16 10.2.0.0/16 dst: 10.1.0.0/16 10.2.0.0/16 xlate src: original |
| |||
| Still having this problem if anybody has any ideas. Each allowed external to internal connection is Accepted on the ingress interface, but then shows Dropped on the egress interface. Thanks |
| |||
| If you're having issues with address spoofing, then perhaps providing some detail on your anti-spoofing configuration, rather than just your NAT rules, might be some help? Just a thought. Remember we only know what you tell us about your network. Some general network setup information would also be helpful. A useful NAT thing to mention might be what you have "Translate destination on client side" set to. Did you have any issues prior to addding those NAT rules? To clarify, are the connections accepted and NATted correctly, even though there are drops logged? Seeing an accept then drop is not entirely unknown, but I would expect that traffic to be dropped, if it is logged as dropped. |
| |||
| Thanks for the reply, I'll try to add some more useful information. Currently my anti-spoofing configuration looks like this: Eth9 Outside Interface > Points to Internet Eth8 Inside Interface > Defined as everything in 128.100.100.0/24 network and everything in the 10.0.0.0/8 network. Allow bi-directional NAT is checked under Automatic NAT rules. Translate Destination on Client Side is checked under both Automatic and Manual NAT rules. A common appearance in the log file is below: Code: if action src dst service eth9 ACCEPT 68.x.x.x 128.100.100.5 21/ftp eth8 DROP 68.x.x.x 128.100.100.5 21/ftp eth9 ACCEPT 68.x.x.x 128.100.100.10 25/ftp eth8 DROP 68.x.x.x 128.100.100.10 25/ftp I hope this helps, I'm glad to provide any other information that would be helpful. Thanks again |
| |||
| Does the 128.100.100/24 network actually physically exist anywhere? Do you also have static NAT rules configured for that inbound traffic (68.x.x.x -> 128.100.100.5)? Or if that 128.100.100/24 network is directly connected, then presumably those are just plain access rules, with no NAT. No clashes with what you're using for hide NAT vs any other static NAT? |
![]() |
| Thread Tools | |
| Display Modes | |
| |