Connection Tracking

Connection Tracking

[Nathan Whittacre]

I have the following situation:

A server for what is called directed host sits behind a NAT'd firewall
with a local IP.  I have port 1066 forwarded to that server(10.2.0.1).
The way this protocol works is that the remote computer connects to it
on port 1066, exchanges some data over the existing connection and then
the server initiates a connection back to the client on the client's
port 1066.  This is fine as long as the client has a static, un-NAT'd
internet IP, but the connection is dropped by the server if it does not
get a reply from port 1066.  I have a few client machines on a NAT'd
network that need to connect to this remote server, but with only one
gateway internet IP.  They do not necessarily need to connect at the
same time.  Is there any way to write a connection tracking script that
senses the outbound connection to port 1066 on the remote side and then
DNATs the inbound 1066 to the local IP once the connection is established?

I have a tcpdump of the connection avaiable if that would be of any help.

Thank you,
Nathan Whittacre

Re: Connection Tracking

[Jim Carter]

On Mon, 6 Oct 2003, Nathan Whittacre wrote:
> The way this protocol works is that the remote computer connects to it
> on port 1066, exchanges some data over the existing connection and then
> the server initiates a connection back to the client on the client's
> port 1066.  This is fine as long as the client has a static, un-NAT'd
> internet IP, but the connection is dropped by the server if it does not
> get a reply from port 1066.  I have a few client machines on a NAT'd
> network that need to connect to this remote server, but with only one

FTP does the same kind of thing except the return port varies; the client
tells the server what port it's listening on.  If you have access to the
NAT box you could perhaps put in a special rule so port 1066 (for the
return connection) was DNATted to just one client's internal IP address and
restricted to just port 1066 rather than the default high-numbered range.
(I assume the client insists on a source port of 1066.)  If it's a
user-owned inexpensive NAT box that you can't configure, you're up the
creek.  I believe the Linksys "Broadband Router" for $80 can do the needed
DNAT.  But then you get into a nightmare of user support issues.

Why the callback?  It really makes things complicated.  If you're trying to
enhance security, as you might with a modem connection, each TCP connection
includes return packets, which will not return if the originator's address
is spoofed.  Also, in principle the Black Hats can invade your ISP and fake
the DNS records.  Much better to use TLS at 4th layer or IPSec at 3rd
layer, and only talk to remote machines that are on your authorization
list.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: Connection Tracking

[Nathan Whittacre]

We do have control over the Nat box.  It is a custom Linux router that 
we put in for these clients.  The biggest problem with the DNATing to a 
specific internat IP is that several client computers will want to use 
it at different times.  So, I don't want to have to change the DNATing 
every time a different computer wants to connect.  As for the 
protocol...  I am not very happy about it either.  We did not define it, 
it is part of the mainframe system installed at the company.  This is 
thier "VPN" --to use the term very loosely-- solution so that this 
manufacturer has installed.  Someone suggested sending the port 1066 to 
the broadcast address.  Although this would probably work, I don't like 
it because of security reasons.  I had thought about doing some type of 
Pptp or Ipsec VPN solution, but all of the different networks run on the 
same address scheme, as per the mainframe manufacturer, which 
complicates things even more.

Nathan

Jim Carter wrote:

>On Mon, 6 Oct 2003, Nathan Whittacre wrote:
>  
>
>>The way this protocol works is that the remote computer connects to it
>>on port 1066, exchanges some data over the existing connection and then
>>the server initiates a connection back to the client on the client's
>>port 1066.  This is fine as long as the client has a static, un-NAT'd
>>internet IP, but the connection is dropped by the server if it does not
>>get a reply from port 1066.  I have a few client machines on a NAT'd
>>network that need to connect to this remote server, but with only one
>>    
>>
>
>FTP does the same kind of thing except the return port varies; the client
>tells the server what port it's listening on.  If you have access to the
>NAT box you could perhaps put in a special rule so port 1066 (for the
>return connection) was DNATted to just one client's internal IP address and
>restricted to just port 1066 rather than the default high-numbered range.
>(I assume the client insists on a source port of 1066.)  If it's a
>user-owned inexpensive NAT box that you can't configure, you're up the
>creek.  I believe the Linksys "Broadband Router" for $80 can do the needed
>DNAT.  But then you get into a nightmare of user support issues.
>
>Why the callback?  It really makes things complicated.  If you're trying to
>enhance security, as you might with a modem connection, each TCP connection
>includes return packets, which will not return if the originator's address
>is spoofed.  Also, in principle the Black Hats can invade your ISP and fake
>the DNS records.  Much better to use TLS at 4th layer or IPSec at 3rd
>layer, and only talk to remote machines that are on your authorization
>list.
>
>James F. Carter          Voice 310 825 2897    FAX 310 206 6673
>UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
>Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)
>  
>

Re: Connection Tracking

[Jim Carter]

On Wed, 8 Oct 2003, Nathan Whittacre wrote:
> We do have control over the Nat box.  It is a custom Linux router that
> we put in for these clients.  The biggest problem with the DNATing to a
> specific internat IP is that several client computers will want to use
> it at different times.  So, I don't want to have to change the DNATing
> every time a different computer wants to connect.

Bummer.  You might plagarize the code from the FTP helper module,
designating the return connection to the NAT box's port 1066 as "related",
which you would then allow through the firewall and which would be
de-NATted so it went to whichever client the original connection belonged
to.  It would be a whole lot easier if the client would accept the return
connection from an arbitrary source port (not just the mainframe's 1066),
so you won't have to think about conntracks hanging around, if a connection
shuts down uncleanly -- as far as the helper module is concerned,
arbitrarily many clients can use the service at once, with different source
ports, even if there's a limit at the mainframe.

But I've never actually tried doing this kind of thing.  Other people on
the list, however, do seem to successfully make special modules.  "Let's
you and him fight" :-)

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Connection Tracking

[Nicole]

Hello everyone,

I would be grateful for some advice. Am writing a target using xtables.
This target saves and restores a field in the IPv{4,6} header to/from
the connection mark.

I have read Jan Engelhardt's booklet (3 July 2012), but remain unclear
on how to ensure that connection tracking is turned on.

My difficulty arises in the following code snippet:

        const struct nf_conn *ct;
        ct = nf_ct_get(skb, &ctinfo);
        if (ct == NULL) {
                return false;
        }
	/* use ct-> */

ct is always false and therefore I cannot do the save and restore.

Any suggestions?

Many thanks

Nicole

Re: Connection Tracking

[Pablo Neira Ayuso]

On Mon, Sep 03, 2012 at 05:35:56PM +0100, Nicole wrote:
> Hello everyone,
> 
> I would be grateful for some advice. Am writing a target using xtables.
> This target saves and restores a field in the IPv{4,6} header to/from
> the connection mark.
> 
> I have read Jan Engelhardt's booklet (3 July 2012), but remain unclear
> on how to ensure that connection tracking is turned on.
> 
> My difficulty arises in the following code snippet:
> 
>         const struct nf_conn *ct;
>         ct = nf_ct_get(skb, &ctinfo);
>         if (ct == NULL) {
>                 return false;
>         }
> 	/* use ct-> */
> 
> ct is always false and therefore I cannot do the save and restore.
> 
> Any suggestions?

Make sure nf_conntrack and nf_conntrack_ipv4 are loaded.

Connection Tracking

[Nathan Whittacre]

I have the following situation:

A server for what is called directed host sits behind a NAT'd firewall 
with a local IP.  I have port 1066 forwarded to that server(10.2.0.1). 
The way this protocol works is that the remote computer connects to it 
on port 1066, exchanges some data over the existing connection and then 
the server initiates a connection back to the client on the client's 
port 1066.  This is fine as long as the client has a static, un-NAT'd 
internet IP, but the connection is dropped by the server if it does not 
get a reply from port 1066.  I have a few client machines on a NAT'd 
network that need to connect to this remote server, but with only one 
gateway internet IP.  They do not necessarily need to connect at the 
same time.  Is there any way to write a connection tracking script that 
senses the outbound connection to port 1066 on the remote side and then 
DNATs the inbound 1066 to the local IP once the connection is established?

I have a tcpdump of the connection avaiable if that would be of any help.

Thank you,
Nathan Whittacre

Connection Tracking

[Amit Kumar Gupta]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

Oops ,

I forget to change the subject.

Sorry for inconvenience.

Regards,
Amit

-----Original Message-----
From: Amit Kumar Gupta 
Sent: Thursday, January 09, 2003 12:09 PM
To: Amit Kumar Gupta
Cc: Netfilter
Subject: RE: can't load the script


Hi All,

I am getting some problem in Connection tracking.

As soon as I execute a program (Having iptables rules), 
It keeps printing the following messages on the screen :-

Ip_contrack: maximum limit of 1016 entries exceeded.

Any the speed becomes damn slow.

Can anybody suggest what is happening?

Thanks & Regards,

Amit Kumar Gupta.

[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 522 bytes --]

**************************Disclaimer**************************************************    
 
 Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' 
and 'confidential' and intended for use only by the individual or entity to which it is 
addressed. You are notified that any use, copying or dissemination of the information 
contained in the E-MAIL in any manner whatsoever is strictly prohibited.

****************************************************************************************

RE: Connection Tracking

[Preston Wade]

Thanks to all that responded.  I guess I need another cup of coffee.  I
completely forgot that if a connection gets closed by either side it moves
into a different state which will put it to one of the other timeout vaules
specified in /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
Thanks,
Preston


> -----Original Message-----
> From:	"Antony Stone" <Antony@Soft-Solutions.co.uk>@INTERNET@HHC 
> Sent:	Friday, June 21, 2002 10:06 AM
> To:	'netfilter@lists.samba.org'
> Subject:	Re: Connection Tracking
> 
> On Friday 21 June 2002 3:54 pm, Preston Wade wrote:
> 
> > Hello All,
> >
> > I am curious to get other peoples thoughts about the 5 Day timeout for
> the
> > following variable: TCP_CONNTRACK_ESTABLISHED.
> 
> 5 days is the value specified in TCP standards, but bear in mind this is
> only
> relevant for connections which have been established (SYN, SYN/ACK, ACK)
> but
> which have not been terminated (FIN or RST).   Connections which get ended
> by
> one party or the other will get removed from the table and the timeout is
> no
> longer relevant.
> 
> > This value seems high for
> > high traffic firewalls.  For instance if I wanted to use netfilter for a
> > firewall between my corporate network and my WAN, which has roughly 2300
> > nodes and 40000 users.  It seems to me like you would run out of STATE
> > memory and with most connection being TCP it would take 5 days before
> most
> > of them would timeout.
> 
> Do you really have large numbers of ESTABLISHED connections which are left
> in
> an open state by clients / servers, instead of being nicely killed off
> with
> FIN or RST packets ?
> 
> The onyl time I've seen this being a real problem was last summer, when
> Nimda
> and Code Red infections started setting up thousands of half-open
> connections
> to machines which couldn't cope with the load....
> 
> > I realize I could modify the value and recompile...
> > although it would be nice to be able to modify these with sysctl.conf or
> > via the /proc filesystem.
> 
> I believe it is possible to change this value on the fly using the
> /proc/sys/net/ipv4 filesystem, although I can't point you at the relevant
> name to use - maybe someone else on this list can remember ?
> 
> 
> 
> Antony.
> 
> 

Connection Tracking

[Preston Wade]

Hello All,

I am curious to get other peoples thoughts about the 5 Day timeout for the
following variable: TCP_CONNTRACK_ESTABLISHED.  This value seems high for
high traffic firewalls.  For instance if I wanted to use netfilter for a
firewall between my corporate network and my WAN, which has roughly 2300
nodes and 40000 users.  It seems to me like you would run out of STATE
memory and with most connection being TCP it would take 5 days before most
of them would timeout.  I realize I could modify the value and recompile...
although it would be nice to be able to modify these with sysctl.conf or via
the /proc filesystem.

Thanks,
Preston

Re: Connection Tracking

[Ramin Alidousti]

I understand the concern. But just a quick question: how many
percent of the TCP sessions of these 2300 nodes and 40000 users
would end up in a dead TCP_CONNTRACK_ESTABLISHED state, ie,
dead sessions with no FIN or RST packet detected? And what
would an acceptable timeout be for these scenarios? If you know
these answers then you could tweak the code to meet your goals.

Ramin

On Fri, Jun 21, 2002 at 09:54:11AM -0500, Preston Wade wrote:

> Hello All,
> 
> I am curious to get other peoples thoughts about the 5 Day timeout for the
> following variable: TCP_CONNTRACK_ESTABLISHED.  This value seems high for
> high traffic firewalls.  For instance if I wanted to use netfilter for a
> firewall between my corporate network and my WAN, which has roughly 2300
> nodes and 40000 users.  It seems to me like you would run out of STATE
> memory and with most connection being TCP it would take 5 days before most
> of them would timeout.  I realize I could modify the value and recompile...
> although it would be nice to be able to modify these with sysctl.conf or via
> the /proc filesystem.
> 
> Thanks,
> Preston
> 

Re: Connection Tracking

[Antony Stone]

On Friday 21 June 2002 3:54 pm, Preston Wade wrote:

> Hello All,
>
> I am curious to get other peoples thoughts about the 5 Day timeout for the
> following variable: TCP_CONNTRACK_ESTABLISHED.

5 days is the value specified in TCP standards, but bear in mind this is only 
relevant for connections which have been established (SYN, SYN/ACK, ACK) but 
which have not been terminated (FIN or RST).   Connections which get ended by 
one party or the other will get removed from the table and the timeout is no 
longer relevant.

> This value seems high for
> high traffic firewalls.  For instance if I wanted to use netfilter for a
> firewall between my corporate network and my WAN, which has roughly 2300
> nodes and 40000 users.  It seems to me like you would run out of STATE
> memory and with most connection being TCP it would take 5 days before most
> of them would timeout.

Do you really have large numbers of ESTABLISHED connections which are left in 
an open state by clients / servers, instead of being nicely killed off with 
FIN or RST packets ?

The onyl time I've seen this being a real problem was last summer, when Nimda 
and Code Red infections started setting up thousands of half-open connections 
to machines which couldn't cope with the load....

> I realize I could modify the value and recompile...
> although it would be nice to be able to modify these with sysctl.conf or
> via the /proc filesystem.

I believe it is possible to change this value on the fly using the 
/proc/sys/net/ipv4 filesystem, although I can't point you at the relevant 
name to use - maybe someone else on this list can remember ?

 

Antony.

Re: Connection Tracking

[Patrick Schaaf]

On Fri, Jun 21, 2002 at 09:54:11AM -0500, Preston Wade wrote:
> 
> I am curious to get other peoples thoughts about the 5 Day timeout for the
> following variable: TCP_CONNTRACK_ESTABLISHED.  This value seems high for
> high traffic firewalls.  For instance if I wanted to use netfilter for a
> firewall between my corporate network and my WAN, which has roughly 2300
> nodes and 40000 users.  It seems to me like you would run out of STATE
> memory and with most connection being TCP it would take 5 days before most
> of them would timeout.  I realize I could modify the value and recompile...
> although it would be nice to be able to modify these with sysctl.conf or via
> the /proc filesystem.

Somehow, that was an impressive summary of a discussion we had here on the
list over and over again. Here's a short key to see why that is status quo:

"seems high" translates to "in rare situations". The default seems
good for the installed base.

"could modify ... and recompile" is true, the exact point where you have
to modify has been pointed out lots of time in the past.

"would be nice to sysctl" is true, and can/could be found in patch-o-matic
somewhere. It's not in the base system because the developers feel to many
knobs hurt. Several past attempts at arguing that position went fruitless.

So, all cases are covered already.

best regards
  Patrick