Bizarre rule requirement

Bizarre rule requirement

[Kevin P. Fleming]

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?

Re: Bizarre rule requirement

[Jason Opperisano]

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

Re: Bizarre rule requirement

[Kevin P. Fleming]

Jason Opperisano wrote:

> here's a thought:  fix your fscking application.

A working SIP ALG would be the fix for my fscking application... but so 
far there isn't one available. What's really happening here is that the 
far end of the "connection" is being moved to a different IP and port; 
the local end is notified of that before it happens, but conntrack has 
no idea it is occurring.

>   # 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

Even that won't quite do it; I don't want to accept all destination UDP 
ports to DNAT to the inside device. I want to accept all _source_ UDP 
ports (from any IP address) as long as they are addressed to the 
randomly-assigned outbound UDP port that my inside device got when it 
sent out the first packet. Yeah, I know, it's screwy and funky.

If I could do it, though, it would allow me to redirect traffic around 
with aplomb, without having to wait for (or try to implement) a SIP ALG.

Re: Bizarre rule requirement

[Jason Opperisano]

On Fri, Dec 31, 2004 at 01:05:48PM -0700, Kevin P. Fleming wrote:
> Jason Opperisano wrote:
> 
> >here's a thought:  fix your fscking application.
> 
> A working SIP ALG would be the fix for my fscking application... but so 
> far there isn't one available. What's really happening here is that the 
> far end of the "connection" is being moved to a different IP and port; 
> the local end is notified of that before it happens, but conntrack has 
> no idea it is occurring.

not free, but appears to do what you want:

  http://www.wifi.com.ar/english/voip.html

free, seems current, not sure if it meets your requirements:

  http://siproxd.sourceforge.net/index.php

i just googled for "linux sip firewall" so i assuming you're aware of
them and already ruled them out for one reason or another.

> >  # 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
> 
> Even that won't quite do it; I don't want to accept all destination UDP 
> ports to DNAT to the inside device. I want to accept all _source_ UDP 
> ports (from any IP address) as long as they are addressed to the 
> randomly-assigned outbound UDP port that my inside device got when it 
> sent out the first packet. Yeah, I know, it's screwy and funky.

explain to me how the above rules would not successfully forward the UDP
traffic to your server, because i must be missing something.  whether or
not it's how you would *like to do it* is immaterial.

-j

Re: Bizarre rule requirement

[Kevin P. Fleming]

Jason Opperisano wrote:

> free, seems current, not sure if it meets your requirements:
> 
>   http://siproxd.sourceforge.net/index.php

It very well could... I've been playing with it, but my ultimate goal 
for this is to put the result onto a Linksys WRT54G/GS running the 
Sveasoft customized firmware. There are versions of siproxd built for 
that box, but I am not yet comfortable that it's reliable enough to 
deploy to client sites (siproxd, that is).

> explain to me how the above rules would not successfully forward the UDP
> traffic to your server, because i must be missing something.  whether or
> not it's how you would *like to do it* is immaterial.

Well, unless I'm misunderstanding, the rules you posted will not work in 
this application because:

1) You are forwarding all inbound UDP traffic to a single device. My 
example was simplified; the final application for this technique could 
have tens of phones behind the NAT, each needing to work this way. 
That's why I phrased my original request the way I did; it was 
predicated on learning the outbound port number and other bits related 
to a specific "connection" (even though this is UDP) and basing the 
inbound rules on those details.

2) You assume that the port number assigned when the phone sends out its 
first UDP packet (from port 4000) by the NAT will also be 4000... it 
very well may not be, if that port is already in use on the public side 
of the NAT for another user. In that case, the FORWARD rule can't work, 
because it doesn't know what port number the conntrack code assigned for 
this specific connection (and it could be different for the next 
connection).

I'll spend some more time working with siproxd to see if it can do what 
I need. If not, I suppose it would be possible to create a netfilter 
module that watched for the outbound UDP and created a RELATED 
connection with the appropriate inbound rule. It wouldn't have to peek 
into the packets at all, just use the information already present in the 
conntrack structures.

Re: Bizarre rule requirement

[Jason Opperisano]

On Fri, Dec 31, 2004 at 03:43:57PM -0700, Kevin P. Fleming wrote:
> 1) You are forwarding all inbound UDP traffic to a single device. My 
> example was simplified; the final application for this technique could 
> have tens of phones behind the NAT, each needing to work this way. 
> That's why I phrased my original request the way I did; it was 
> predicated on learning the outbound port number and other bits related 
> to a specific "connection" (even though this is UDP) and basing the 
> inbound rules on those details.
> 
> 2) You assume that the port number assigned when the phone sends out its 
> first UDP packet (from port 4000) by the NAT will also be 4000... it 
> very well may not be, if that port is already in use on the public side 
> of the NAT for another user. In that case, the FORWARD rule can't work, 
> because it doesn't know what port number the conntrack code assigned for 
> this specific connection (and it could be different for the next 
> connection).

i didn't assume anything, i proposed a broad-sword-hack-work-around
that met the requirements of the simplified scenario you presented.
say what you mean and mean you say.

now that we know the real situation/requirements--maybe someone else can
be of more use; as i have no experience with netfilter+VoIP--just
commercial firewalls (which magically work as a side-effect of their
hefty price tags).

l8er.

-j