Why do I see two entries for a single instance of port forwading?

Firmware 8.1 on a Balance 20x.
The router has port forwarding enabled for RDP (TCP port 3389). There is also an inbound firewall rule that allows the forward and logs it.
The first time it logged an instance of RDP passing through the router, there were two log entries as shown here.
Anyone know why? Is this an RDP thing? I have been logging port forwarding for VNC for quite a while and that only creates one log entry per instance.

Are you using IP forwarding on WAN1? If so, I don’t think you need the port forwarder. Port forwarding is used when NAT is taking place. I am wondering if the first entry is the original packet just being routed through the firewall, and the second is the port forwarded packet.

The source port for the second entry is incremented by one which indicates a second connection attempt.

If this traffic is traversing VLans, one entry could be for WAN to untagged LAN, and the second is LAN to VLan.

Just throwing some ideas out… they are definitely worth what you paid for them. :slight_smile:

Not sure what you mean by IP forwarding on WAN1. No VLANs, but that’s a great guess.

Maybe its the RDP server asking for a password and the RDP client auto-answering with the password? The password is saved in the RDP client.

Eventually, I will get to try this with VNC to compare to older firmware versions.

@Michael234, sound like 2 sessions were created by the RDP. I notice there are using different source ports.

1 Like

I asked about IP Passthrough because your source IP is and your destination is Those are both private IP spaces - it caught me off guard, most of the time the WAN is on some kind of public IP from the ISP. Do you have more than one router in this network chain?

This was my first time logging RDP. I make a habit of logging forwarded ports but up till now had only been using VNC. So, it may be perfectly normal.

Yes, two routers - an “inner” and an “outer”. The 192.168.1.x subnet is the outer router connected to ISP and the 192.168.8.x is the inner one connected to outer one.

And are you using NAT on the “inner” router? If not, you don’t need the forwarder. With IP forwarding, all traffic destined for an IP is routed to that IP (if the firewall allows it). I would imagine that a forwarder combined with IP forwarding would result in a duplicate packet going out.

Here is the option I am talking about…

1 Like

Good to know about this feature you point out as well…

I think for the op, the whole idea is he wants to protect the RDP server using the firewall of the inner router and only expose & forward the minimum number of ports possible on the inner router (in this case just 1) instead of forwarding everything using the option you point out.

According to a network segmentation doc in a series of NSA networking security docs for public consumption, it says use of another router for segmentation is even more secure than using a single router and implementing the segmentation via the more common method of using a VLAN + similar firewall rule & ACL’s on a single router.

That’s what you’re doing right @Michael234 ?

@jmjones Sorry that I missed your response. The inner router is using NAT. I have no idea what IP forwarding is/does.

@datahead Yes, the firewall in the inner router is important, protecting devices connected to the router behind a 2nd firewall. Plus, I was not aware of IP Forwarding :slight_smile: Might you have a link to those NSA networking security documents?


Sure, there’s a whole series of them, but here’s the one with the specific excerpt and Iine about well-implemented physical segmentation being more secure than virtual/software-defined segmentation that I thought of the other day when I commented above.

This is by no means my field of study or expertise in life and I love learning so by all means please fill me and anyone who may comes across this thread if I’m misinterpreting anything, or some more context is needed, etc.

The only thing I’m unsure of is whether or not the author is saying in the sentence in bold face,
that if you decide to connect these isolated network segments, physical segmentation is still more secure on the condition that “application-aware detection devices” are placed between the routers and/or switches…
And what that means exactly…active fancy layer 7 firewalls? , UTM’s, passive monitoring? … or if using routers, would their built-in firewalls also meet this condition if they can block applications ?

Physical segmentation uses the configuration and placement of physical devices like routers and switches to create network segments based on functional importance and/or levels of access. Each of these segments can be configured to be physically isolated or connected together using application-aware detection devices. With proper filtering rules and policy implemented at the border of each segment, physical segmentation is the most secure method of segmentation and provides the most protection against adversary lateral movement. However, this technique can be expensive as it requires the use of separate infrastructure for every subnetwork and requires extensive out of band network management.

Segment Networks and Deploy Application-aware Defenses
U/OO/184967-19 | PP-19-1040 | SEPTEMBER 2019

National Security Agency | Cybersecurity Information

Here’s the NSA series I referred to:

Similar commentary in a context where NSA advises a physically segmented-off network to manage networking devices is more secure than use of anything segmentation that’s virtually based…VLANS, and more complex things like microsegmentation and VRF

This virtual segmentation can be implemented using multiple Virtual Local Area Networks (VLANs), Virtual Routing and Forwarding (VRFs), VPNs, or other zero trust and micro-segmentation technologies. The major vulnerability in these configurations is potential data leakage where devices on the operational network may capture sensitive management traffic…

Performing Out-of-Band Network Management
National Security Agency | Cybersecurity Information
U/OO/169570-20 | PP-20-0807 | Sep 2020 ver. 1.0