Changing ports enoute
 

In an example log entry below, I'm showing an SPT (I guessing source port) of 32771, and a DPT (guessing destination port) of 53 (DNS).

Why two different ports? Is the port assignment getting changed between the sending NIC and receive NIC? Or am I reading this wrong? I'm wondering how to handle these in my iptables.

Thank you!

Tom D.

It's called session multiplexing, if I remember properly.

That's what allows you to open multiple sessions to the same host. For example, when you connect to a web server, if you only connected to and from port 80, you'd only be able to have one session open. That's slow and inefficient. So you hit the same web server from a multitude of source ports, and they all point at port 80; you can get several requests at once from a single web server.

Anyway, it's normal and all good. Generally, you filter your outbound traffic by destination port, or IP. You filter your inbound via source port, or IP. So for a DNS request, you'd want to allow anything out destined for port 53, and anything in sourced from port 53.

Decent explanation?

well it's not really called anything, that's just the way tcp sockets work.

client / source port numbers are picked generally from an "ephemeral" range, which is a block of space somewhere above port 1024, often way past there, which any process is allowed to open. non-root processes can't open a port under 1024 for security reasons, but essentially there is no relation between a source and destination port (except in some unusal cases like dhcp)

a tcp connection is defined as client_ip:client_port <--> server_ip:server_port and both parties keep track of those 4 attributes (amongst others relevant within that known connection) and so know what connection that is.

Yes, it is called multiplexing. Here are a few web sites to describe it.

http://ntrg.cs.tcd.ie/undergrad/4ba2...t/5.cd.03.html
http://www.citap.com/documents/tcp-ip/tcpip013.htm
http://www.tcpipguide.com/free/t_TCP...pplicati-2.htm

It's not "just the way TCP sockets work." It's done for a reason, and a rather good one.

well i know it's for a reason..! Just that it's such a fundamentally low level piece of TCP/IP, it's not something that you actively look to modify or question to any extent.

Sure you question it. That's how you learn. :)

Not to mention, knowing why it does what it does can come in handy later. Take this, for example. The OP had no knowledge of TCP/IP multiplexing, and as far as he knew, his ports were getting switched around en-route.

Imagine when he saw several connections to the same server from different ports. Someone not having knowledge of why this happens could be a little freaked out, and that's never good (although it can be funny.) lol

Personally, I've never accepted, or given a "just because" answer. While you can't change it, in depth knowledge of how something works is much better. Imagine if your phones were set up and the TDM used to separate phone calls was just accepted and never improved upon. You wouldn't have TDM over fiber, you wouldn't really have modems, and you wouldn't have DSL (since it uses frequency division multiplexing). Same with TCP/IP multiplexing; if you don't question how it works, you'll never know how it works, why it works, why it's implemented, and the massive number of uses for it.

Just imagine, as another example, if I just accept QoS for what it is in my job, but had no understanding of it. I'd have 4000 very unhappy VoIP users on my network, and I'd have no clue what was going on.

ever wished you'd not phrased something the way you had?

qos?

Router(config-if)#auto qos voip
Router(config-if)#

what's to learn?? ;)

if you use Cisco Call Manager like we do, you've probably got 4000 unhappy users whatever you do.

LOL. Noooooo. Never! :rolleyes:

Not to sound demeaning, but auto qos voip illustrates where "just because" can get you.

While it can be used to QoS a network, it is not the end-all-be-all to QoS solutions, nor should it really be used permanently. It is a tool for base lining the QoS your network should need, and is a suggestion. You can choose to continue using it or not, but it will not always solve your problems. Cisco actually doesn't recommend you implement it as a permanent solution on your network.

Found in this thread regarding CCIE-V from NetPro: http://forum.cisco.com/eforum/servle...lected_message

The post is from BennG.

We actually use CallManagers; around 14 of them. Users are actually rather happy because the network is properly designed and the 6 engineers responsible for it have have in-depth knowledge of networking and the protocols.

The story of my life. :(

Note to self. Never make jokes to ARC1450.

I never joke. 100% serious.

Am I serious, or am I joking? The world may never know. ;)

Now see, if you'd have said Unity and Lotus were the bestest of buddies and worked flawlessly together, there's a joke. You'd have had me in stitches for the next 6 months with that. :-P

Keep in mind, I just came off a job with a "network manager" that thought himself a Cisco god. The guy barely knew what QoS stood for, and had absolutely no good words for Cisco's AVVID implementation.

Ahh...That makes sense. It had my curiousity.

Now I just have to figure out how to make those adjustments in the firewall.

Thanks much for the help!

Tom D.
Denver, Colorado

well the source port is *very* seldom deemed "interesting" in firewall rulesets, only the destination.

Agreed. I actually can't think of any situation I worry about the source port, except in the case of NTP.