IPTABLES and RELATED states

Hi,

Is it possible to accept a connection to a new port if another
connection from the same orginating IP has been accepted to a different
port. For example;

iptables -A FORWARD -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 3389 -m --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD DROP

The client connects to HTTPS (tsweb), since the client now has an
active HTTPS link to the firewall it now allows the same client through
port 3389.

Now this doesn't work just hoped it might give you an idea of what I am
trying to do, personally I dont think it's possible!

Thanks
Andrew

On 26 Jul 2005 08:17:46 -0700, "Andrew Townsend" <(E-Mail Removed)> wrote:
>
> Is it possible to accept a connection to a new port if another
> connection from the same orginating IP has been accepted to a different
> port. For example;
What is it you want to do?
>
> iptables -A FORWARD -i eth0 -p tcp --dport 443 -j ACCEPT
> iptables -A FORWARD -i eth0 -p tcp --dport 3389 -m --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD DROP
The above makes no logical sense to me,
>
> The client connects to HTTPS (tsweb), since the client now has an
> active HTTPS link to the firewall it now allows the same client through
> port 3389.
>
LAN egress? Reaching a server on firewall is through input chain.
LAN ingress to server is not firewall but DMZ, a different animal.

> Now this doesn't work
No, as it defines nonsense?

The state ESTABLISHED,RELATED is used to accept expected return
traffic on (usually) high port associated with an outgoing
connection, for example you connect to an external web server,
the expected return traffic is let back in on ports you would
_not_ accept new connections on.

Rules with --dport are incoming, thus handled by firewall, thus
belong to the INPUT chain rather than the FORWARD chain.

If I knew what you trying to achieve I could show you an example...

Grant.

Heh, well it made perfect sense to me Let me try again!

It's ingress:

TS Server |-----eth1--| Linux |--eth0------| Internet

Using DNAT, ports 443 & 3389 are forwarded to the TS Server through the
Linux box.

iptables -A FORWARD -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 3389 -m --state
ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A PREROUTING -i eth0 -p --dport 443 -j DNAT --to
tsserver
iptables -t nat -A PREROUTING -i eth0 -p --dport 3389 -j DNAT --to
tsserver

I need to secure port 3389 at Level 3 since I am unable to do it with
certificate auth with MS, however port 443 IS secured with cert. auth.

I do not want to limit who can connect to 3389, my only requirement is
that first they have FORWARED traffic through 443 before the Linux box
will accept FORWARDED connections through 3389. The simpliest way would
be to just change the port the linux box listens on for 3389 but I want
to avoid this incase there is a way of securing 3389.

I understand what you are saying about states, I have used them many
times before.

In article <(E-Mail Removed) .com>,
Andrew Townsend <(E-Mail Removed)> wrote:
:Heh, well it made perfect sense to me Let me try again!
:
:It's ingress:
:
:TS Server |-----eth1--| Linux |--eth0------| Internet
:
:Using DNAT, ports 443 & 3389 are forwarded to the TS Server through the
:Linux box.
:
:iptables -A FORWARD -i eth0 -p tcp --dport 443 -j ACCEPT
:iptables -A FORWARD -i eth0 -p tcp --dport 3389 -m --state
:ESTABLISHED,RELATED -j ACCEPT
:
:iptables -t nat -A PREROUTING -i eth0 -p --dport 443 -j DNAT --to
:tsserver
:iptables -t nat -A PREROUTING -i eth0 -p --dport 3389 -j DNAT --to
:tsserver
:
:I need to secure port 3389 at Level 3 since I am unable to do it with
:certificate auth with MS, however port 443 IS secured with cert. auth.
:
:I do not want to limit who can connect to 3389, my only requirement is
:that first they have FORWARED traffic through 443 before the Linux box
:will accept FORWARDED connections through 3389. The simpliest way would
:be to just change the port the linux box listens on for 3389 but I want
:to avoid this incase there is a way of securing 3389.
:
:I understand what you are saying about states, I have used them many
:times before.

I don't see how you're going to accomplish that without writing a
custom ip_conntrack_https module to create a tracking entry so that
port 3389 can be seen as RELATED traffic. As things stand, https
(port 443) is not a complex protocol for connection tracking, so
there is no such thing as traffic RELATED to an https connection.

I looked briefly at the modules available from http://netfilter.org/
and didn't see anything there that looked promising.

--
Bob Nichols AT comcast.net I am "rnichols42"