0

Ok, so I have a SonicWall TZ 205 that is providing perimeter security for a small office. The crux of my problem is this, users are not able to access published services over the public IP when behind this device.

The Situation:
There are 3 zones and 2 border devices involved here.
Zone: Ye Olde Internet
Device: Standard ISP provided cable modem (out: Public IP in: 192.168.1.1)
Zone: a "proto dmz" network shared with unrelated and uncontrolled routers/devices
Device: The TZ 205 GW (out:192.168.1.10 in:10.1.1.254) Zone: Office LAN

Note: There are port mapping rules setup on both devices which are working correctly. Also while I can configure the modem, I can not place the other devices behind the GW. (consider them other tenants) As such I can't take the obvious shortcut and just assign the public ip to the GW.

Traffic flows properly from traffic originating on the WAN to published hosts on the LAN and vice versa. Even traffic from the LAN to 192.168.1.10 is allowed properly.

However, traffic from the LAN to the public IP for internal services (eg https) is dropped with a "Land attack dropped" message. E.g.

Source 192.168.1.10, 28827, X1
Destination 192.168.1.10, 80

I have a general idea of what that filter is looking for, but how do you tell it to EXEMPT this particular traffic? I just can't figure out where the setting is or what rule to make. I feel like I'm missing something obvious :-\

feamsr00
  • 62
  • 1
  • 9
  • 3
    *"users are not able to access published services over the public IP when behind this device."* - That sounds like a [hairpin NAT](http://serverfault.com/q/55611/37681) problem. – HBruijn Oct 29 '16 at 05:20
  • Ah. Interesting. I didn't know that term. That said, based on what I've read so far, this device can recognise that *specific, simple scenario* (where pertinent IPs are already assigned to its own interfaces). In particular, I'm hoping to config, bypass, or disable this particular "land attack" rule. – feamsr00 Oct 31 '16 at 20:00

1 Answers1

1

The firewall thinks this is a LAND attack because the source and destination IP address of those packets are the same. You can solve this by translating the source of the outbound packets to another address, e.g. 192.168.1.11

hertitu
  • 337
  • 1
  • 6
  • This is a curious solution. Is really best to use a "fake" IP? For the record `.11` is used by another "tenant". What would be some issues with that? Surely it would be better to get the device to recognise the situation properly? Unless that's impossible... :-\ – feamsr00 Oct 31 '16 at 19:51
  • Yes obviously you need to use another address in 192.168.1.0/24 that is not currently in use yet. But I wouldn't call this a *fake* ip address, what is fake about it? I see it as the *client* NAT address, and .10 is then your *server* NAT address. To disable this LAND attack check, I have to be honest, I have no idea on Sonicwall. – hertitu Oct 31 '16 at 21:33