DrayTek UK Users' Community Forum

Help, Advice and Solutions from DrayTek Users

NAT sessions table - how *should* it look?

  • uli08
  • Topic Author
  • User
  • User
More
16 Feb 2019 01:18 #1 by uli08
Sorry if following question is blindingly obvious... I did look for the answer but couldn't find it.

Using a Draytek Vigor2920, looking at "Diagnostics"->"NAT Sessions Table". What I see there is a large number of active NAT sessions that list the router's own IP as the "private IP".

From my basic understanding of what NAT is & does, I would have expected only/mostly sessions where the private IPs in the table are those of my devices on the network, but not of the router itself. There are of course several such sessions - my PC talking to the outside world, for example, showing the PC's own IP address as the "private IP" in the NAT sessions table. But those few sessions are completely outnumbered by sessions that list the router itself as the "private IP".

Is this normal? Or is the router compromised? Am I misunderstanding something?

Thanks, Uli

Please Log in or Create an account to join the conversation.

  • hornbyp
  • User
  • User
More
16 Feb 2019 23:50 #2 by hornbyp

uli08 wrote: But those few sessions are completely outnumbered by sessions that list the router itself as the "private IP".i


FWIW, neither of my Vigors (2830+2860) show the Router as having a NAT session to the outside world.

What's the IP address that your 2920 is talking to? Can you think of a plausible reason for such connection(s)? Maybe you can firewall them and provoke a reaction from something?

Please Log in or Create an account to join the conversation.

  • uli08
  • Topic Author
  • User
  • User
More
19 Feb 2019 00:57 #3 by uli08

hornbyp wrote:

uli08 wrote: But those few sessions are completely outnumbered by sessions that list the router itself as the "private IP".i


FWIW, neither of my Vigors (2830+2860) show the Router as having a NAT session to the outside world.

What's the IP address that your 2920 is talking to? Can you think of a plausible reason for such connection(s)? Maybe you can firewall them and provoke a reaction from something?



Thanks very much for checking this & posting it. So something is not right. I think I found the reason - it's a convoluted problem of unexpected DMZ behaviour. Disabling DMZ kills the sessions.

In case this helps anyone else: I had configured a DMZ to an IP address that is not actually connected (no physical device on the LAN that serves the DMZ IP). At the same time I added a route that directs traffic from the DMZ IP to the outside world using NAT under a WAN IP alias (under "Load-Balance/Route Policy"). If you ask why I did all that - it's a left-over configuration for an Xbox that I since binned. The WAN IP alias was put in place so that the downstream networking (towards the WAN) could separate the Xbox traffic from the rest of the traffic coming through the router's NAT.

The net effect seems to be that people from the outside can somehow traverse the router back to the outside (under my IP address). That's not good, obviously. It's reproducible - a couple of minutes running this configuration and I see unwanted connections popping up in my NAT sessions table (among others I found NAT sessions to IP addresses in places like Turkey, China, Iran, Iraq). Disabling the DMZ kills these sessions.

Again, this is without any LAN device actually operating under the DMZ IP address. Maybe Draytek want to check whether this is a bug? I'm not enough of an expert to judge, but if there's no actual DMZ device why should the incoming DMZ traffic be NAT'd back to the outside - if that is indeed what is happening here?

Please Log in or Create an account to join the conversation.

  • hornbyp
  • User
  • User
More
19 Feb 2019 12:30 #4 by hornbyp

uli08 wrote: The net effect seems to be that people from the outside can somehow traverse the router back to the outside (under my IP address). That's not good, obviously. It's reproducible - a couple of minutes running this configuration and I see unwanted connections popping up in my NAT sessions table (among others I found NAT sessions to IP addresses in places like Turkey, China, Iran, Iraq).



I do see something which is a little similar to that (which is why your original post caught my eye) ...

I have a SYSLOG enabled firewall rule, which is a default block for inbound traffic. Every once in a while, it blocks and reports traffic such as :-

116.105.102.105 (Vietnam) => 99.97.116.101 (Chicago) , protocol 67 (DHCP?).

Without the firewall rule, would that succeed? and why is it routing via my IP address ?

The targetted ports are many and various (some make no sense) and it only happens sporadically. It happens on both my Virgin media Docsis connection and my Zen VDSL connection.

Please Log in or Create an account to join the conversation.

  • uli08
  • Topic Author
  • User
  • User
More
20 Feb 2019 20:55 #5 by uli08

hornbyp wrote:

uli08 wrote: The net effect seems to be that people from the outside can somehow traverse the router back to the outside (under my IP address). That's not good, obviously. It's reproducible - a couple of minutes running this configuration and I see unwanted connections popping up in my NAT sessions table (among others I found NAT sessions to IP addresses in places like Turkey, China, Iran, Iraq).



I do see something which is a little similar to that (which is why your original post caught my eye) ...

I have a SYSLOG enabled firewall rule, which is a default block for inbound traffic. Every once in a while, it blocks and reports traffic such as :-

116.105.102.105 (Vietnam) => 99.97.116.101 (Chicago) , protocol 67 (DHCP?).

Without the firewall rule, would that succeed? and why is it routing via my IP address ?

The targetted ports are many and various (some make no sense) and it only happens sporadically. It happens on both my Virgin media Docsis connection and my Zen VDSL connection.



I spent more time testing this, also going in from the outside from another Internet connection, and have come to a different conclusion now. What actually happens: You have an open port (or a DMZ) defined on your router pointing to some IP address that isn't served by an actual device on your network (as described earlier).

Now some bad guy scans your ports from the outside. Even though the ports are forwarded, this scan goes nowhere (no response on their end) because there's no device connected. But Draytek "NAT Sessions Table" will show an active session that indicates the DMZ/open port IP address is actually connected to the bad guy's IP address.

So if you get scanned a lot, you will get a lot of very odd entries in your NAT Sessions Table, to a LAN IP address that isn't actually served by a device. But they don't mean anything (at least I think they don't). My initial mistake was that I noticed all these sessions and thought they are actually routed connections - I no longer think that's actually true. It's just the way the NAT Sessions Table on the Draytek router works - it shows these 'duds' that don't actually do anything.

Re your description, my basic understanding would be that the default firewall rules of the router should kill such attempts anyway. But maybe someone more qualified can explain what these log entries actually mean, where they come from, and whether or not they require a separate firewall route? ...or alternatively recommend a good book on the subject ;-)

Please Log in or Create an account to join the conversation.

  • uli08
  • Topic Author
  • User
  • User
More
20 Feb 2019 21:19 #6 by uli08
Sorry for verbosity - if anyone is looking for answers from all this - I realise I confused two separate issues I had in my NAT Sessions Table:

1) Entries where my DMZ IP address showed active sessions when there was no device connected - that's resolved now as described in the last post.

2) Entries where my router itself showed as being the LAN part of active sessions - that disappeared when I removed the "extra" route added through "Load-Balance/Route Policy" as described.

Sorry if this is confusing in the various posts so far.

Please Log in or Create an account to join the conversation.