Re: Bizarre rule requirement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux