All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Opperisano <opie@817west.com>
To: netfilter@lists.netfilter.org
Subject: Re: Bizarre rule requirement
Date: Fri, 31 Dec 2004 14:54:06 -0500	[thread overview]
Message-ID: <20041231195406.GA7578@bender.817west.com> (raw)
In-Reply-To: <41D5A87C.4040508@starnetworks.us>

On Fri, Dec 31, 2004 at 12:29:00PM -0700, Kevin P. Fleming wrote:
> I have an application that needs an unusual rule, and I don't think I 
> can construct it using standard netfilter targets (in 2.6 kernel series).
> 
> I have a Linux machine configured as a NATing firewall using 
> iptables/netfilter; it has a public IP and a private IP on separate 
> NICs, standard config.
> 
> On the private LAN, there is a node (at 10.1.1.2) that sends out UDP 
> (from port 4000) to a public IP of 200.200.200.1 (made up <G>) at port 
> number 5000.
> 
> When this passes through the NAT, the source IP address and port number 
> change to 100.100.100.2 (the public IP of the NAT) and port 32450 
> (random assignment).
> 
> Because we allow ESTABLISHED return traffic, UDP packets coming from 
> 200.200.200.1 sent to 100.100.100.2 port 32450 are accepted and 
> de-NATted back to 10.1.1.2 port 4000. This is good :-)
> 
> However, I need to modify this a bit; I need to accept traffic from 
> _any_ IP address/port to port 32450 on the NAT, and have it forwarded to 
> 10.1.1.2 port 4000, as long as 10.1.1.2 continues to send outbound 
> packets and keep the "connection" alive. In other words, I need the 
> "conntrack" data to be asymmetric:
> 
> Outbound: 10.1.1.2/32:4000 > 200.200.200.1:5000
> Inbound: 0.0.0.0/0:(any) > 10.1.1.2/32:4000
> 
> Is something like this possible?
> 

here's a thought:  fix your fscking application.

beyond that--state tracking can't help you:

  # DNAT all UDP ports to 10.1.1.2 port 4000
  iptables -t nat -A PREROUTING -i $EXT_IF -p udp \
    -j DNAT --to-destination 10.1.1.2:4000

  # accept all udp port 4000 packets to 10.1.1.2
  iptables -A FORWARD -i $EXT_IF -p udp -d 10.1.1.2 --dport 4000 \
    -j ACCEPT

if those keep-alive packets are of a fixed length--you can use the
length match to limit you exposure with that DNAT rule.

another option would be to fix your fscking application.

-j


  reply	other threads:[~2004-12-31 19:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-31 19:29 Bizarre rule requirement Kevin P. Fleming
2004-12-31 19:54 ` Jason Opperisano [this message]
2004-12-31 20:05   ` Kevin P. Fleming
2004-12-31 20:40     ` Jason Opperisano
2004-12-31 22:43       ` Kevin P. Fleming
2004-12-31 22:51         ` Jason Opperisano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041231195406.GA7578@bender.817west.com \
    --to=opie@817west.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.