(unknown)

(unknown)

[Sebastian Seemann]

Hi,

I would like to DROP all connections from IPs originating in a specified country. Of course, the geoip extension is a perfect fit for that. My question is what happens if I do this:

iptables -P INPUT DROP
iptables -A INPUT -m geoip ! --src-cc [country] -j ACCEPT

What happens if an IP is not found in the geoip-database, so it has no country-code at all? Is it accepted or not?
I would suppose it is accepted and, since I wanna be sure, would be thankful for a workaround simpler than adding every country in the world but the forbidden one.

Best Regards,
Sebastian
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Re:

[Grant Taylor]

On 10/4/2008 6:20 AM, Sebastian Seemann wrote:
> What happens if an IP is not found in the geoip-database, so it has 
> no country-code at all? Is it accepted or not?

I don't know for sure what the GeoIP match extension will do if the IP 
is not in the database.  I would expect the match to fail.  However with 
inverse logic included I'd guess that the failure would turn in to a 
success.  But with out testing, this is only a guess.

> I would suppose it is accepted and, since I wanna be sure, would be 
> thankful for a workaround simpler than adding every country in the 
> world but the forbidden one.

I would be tempted to re-write your rule like this

    iptables -A INPUT ! -m geoip --src-cc [country] -j ACCEPT

The difference being that you are moving the negative logic out of an 
unpredictable failure situation (GeoIP not knowing where the IP is from) 
to a controlled situation (IPTables inverting the result of a match 
extension).

Further, the GeoIP match extension should only return a successful match 
/if/ the source IP is in said source country.  Rather GeoIP will not 
match if the IP is included in the database but not associated with said 
country.  Likewise GeoIP should not success on an unknown IP because it 
could not make a match.

With GeoIP behaving more predictably you can have IPTables test for 
GeoIP *NOT* matching.



Grant. . . .

Re:

[Grant Coady]

On Sun, 05 Oct 2008 00:14:30 -0500, Grant Taylor <gtaylor@riverviewtech.net> wrote:

>On 10/4/2008 6:20 AM, Sebastian Seemann wrote:
>> What happens if an IP is not found in the geoip-database, so it has 
>> no country-code at all? Is it accepted or not?
>
>I don't know for sure what the GeoIP match extension will do if the IP 
>is not in the database.  I would expect the match to fail.  However with 
>inverse logic included I'd guess that the failure would turn in to a 
>success.  But with out testing, this is only a guess.
>
>> I would suppose it is accepted and, since I wanna be sure, would be 
>> thankful for a workaround simpler than adding every country in the 
>> world but the forbidden one.
>
>I would be tempted to re-write your rule like this
>
>    iptables -A INPUT ! -m geoip --src-cc [country] -j ACCEPT
>
>The difference being that you are moving the negative logic out of an 
>unpredictable failure situation (GeoIP not knowing where the IP is from) 
>to a controlled situation (IPTables inverting the result of a match 
>extension).
>
>Further, the GeoIP match extension should only return a successful match 
>/if/ the source IP is in said source country.  Rather GeoIP will not 
>match if the IP is included in the database but not associated with said 
>country.  Likewise GeoIP should not success on an unknown IP because it 
>could not make a match.

Looking at the source, geoip is very careful to make sure the IP is 
within a particular IP block to return match, so it should 
return no match for missing IP.  The maxmind database is sparse, as 
not all IPs appear within it.
>
>With GeoIP behaving more predictably you can have IPTables test for 
>GeoIP *NOT* matching.

Sounds good.

Grant.

Re: Re:

[Sebastian Seemann]

> On Sun, 05 Oct 2008 00:14:30 -0500, Grant Taylor
> <gtaylor@riverviewtech.net> wrote:
> 
> >I don't know for sure what the GeoIP match extension will do if the IP 
> >is not in the database.  I would expect the match to fail.  However with 
> >inverse logic included I'd guess that the failure would turn in to a 
> >success.  But with out testing, this is only a guess.
> >
> >I would be tempted to re-write your rule like this
> >
> >    iptables -A INPUT ! -m geoip --src-cc [country] -j ACCEPT

> >The difference being that you are moving the negative logic out of an 
> >unpredictable failure situation (GeoIP not knowing where the IP is from) 
> >to a controlled situation (IPTables inverting the result of a match 
> >extension).
Ah, I see. So simple but so great. Thank you.

> >Further, the GeoIP match extension should only return a successful match 
> >/if/ the source IP is in said source country.  Rather GeoIP will not 
> >match if the IP is included in the database but not associated with said 
> >country.  Likewise GeoIP should not success on an unknown IP because it 
> >could not make a match.
Good to know. That is exactly what I was wondering about.

> Looking at the source, geoip is very careful to make sure the IP is 
> within a particular IP block to return match, so it should 
> return no match for missing IP.  The maxmind database is sparse, as 
> not all IPs appear within it.
Maxmind write on their homepage the free database, while containing subnets, is right in 99.3 % of the cases, excluding AOL-users, which always are reported as US. I think this, if it is true, is sufficient for me, as long as unknown users are avoided.

Thanks guys.

Regards,
Sebastian
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Re: Re:

[Sebastian Seemann]

  -------- Original-Nachricht -------- > Datum: Sun, 05 Oct 2008 10:45:18 +0200 > Von: "Sebastian Seemann" <MisterSeaman@gmx.de> > An: netfilter@vger.kernel.org > Betreff: Re: Re:  > > On Sun, 05 Oct 2008 00:14:30 -0500, Grant Taylor
> > >I would be tempted to re-write your rule like this
> > >
> > >    iptables -A INPUT ! -m geoip --src-cc [country] -j ACCEPT
> 
> > >The difference being that you are moving the negative logic out of an 
> > >unpredictable failure situation (GeoIP not knowing where the IP is
> from) 
> > >to a controlled situation (IPTables inverting the result of a match 
> > >extension).
> Ah, I see. So simple but so great. Thank you.
In fact, sadly this doesn't seem to work in general. iptables reports 
"unexpected ! flag before match". This was with iptables 1.4.0. Any 
other ideas?

Regards,
Sebastian

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

RE:

[JO Bower]

Your email address has brought you an unexpected luck, which was selected in The Euro Millions Lottery and subsequently won you the sum of €1,000,000.00 Euros. Contact Monica Torres Email: monicatorresesp@gmail.com to claim your prize.

How to make bi-directional NAT'ting?

["Яцко Эллад Геннадьевич (ngs)"]

Hello!

I have some specific problem with Cisco CP7961G IP phone.
It sends packets to external Softswitch using one UDP port
which differs from 5060 (voipControlPort in its .XML), but
it waits answers on 5060!
And I can't do anything with it! I have tried Firmware from
8.0.x up to 8.5.x - all the same!

One thing I think is make corresponding translation on IPTables.
SNAT in direct path (from 79161 to Softswitch) and DNAT
in backward direction (from outside Softswitch to 7961).

BUT IT DOESN'T WORK! :-)

$IPTABLES -t nat -A PREROUTING          -p udp -s 80.251.x.x 
                         -d 80.251.y.y --dport 5060 -j DNAT 
--to-destination 172.16.128.200:5060
$IPTABLES -t nat -A POSTROUTING -o eth0 -p udp -s 172.16.128.0/24 
--sport 1024:65535 -d 80.251.x.x --dport 5060 -j SNAT --to-source      
80.251.y.y:5060

What do I do wrong?

Kind regards,
Ellad Yatsko

Re: How to make bi-directional NAT'ting?

[Tyler J. Wagner]

On 2011-08-23 09:26, "яцко Ёллад √еннадьевич (ngs)" wrote:
> Hello!
> 
> I have some specific problem with Cisco CP7961G IP phone.
> It sends packets to external Softswitch using one UDP port
> which differs from 5060 (voipControlPort in its .XML), but
> it waits answers on 5060!
> And I can't do anything with it! I have tried Firmware from
> 8.0.x up to 8.5.x - all the same!
> 
> One thing I think is make corresponding translation on IPTables.
> SNAT in direct path (from 79161 to Softswitch) and DNAT
> in backward direction (from outside Softswitch to 7961).
> 
> BUT IT DOESN'T WORK! :-)
> 
> $IPTABLES -t nat -A PREROUTING          -p udp -s 80.251.x.x
>                         -d 80.251.y.y --dport 5060 -j DNAT --to-destination
> 172.16.128.200:5060
> $IPTABLES -t nat -A POSTROUTING -o eth0 -p udp -s 172.16.128.0/24 --sport
> 1024:65535 -d 80.251.x.x --dport 5060 -j SNAT --to-source      80.251.y.y:5060

SIP is difficult to correct with NAT. It includes connection data at layer
7. So the Softswitch may be ignoring packet headers and replying to that.

I don't think NAT is your solution here. Something else is wrong in the SIP
setup of this device.

Regards,
Tyler

-- 
"[...] the effectiveness of pat-downs does not matter very much, because
the obvious goal of the TSA is to make the pat-down embarrassing enough
for the average passenger that the vast majority of people will choose
high-tech humiliation over the low-tech ball check."
   -- Jeffrey Goldberg, "For the First Time, the TSA Meets Resistance"
      The Atlantic, 2010-10-29

Re:

[Tyler J. Wagner]

On 2011-08-23 12:08, Ellad Yatsko wrote:
> Main problem is DNAT does not work as I wait. It seems to me there is an
> implicit additional
> DNAT rule for SNAT, and because *my* DNAT rule does not work. May you show
> me how it
> could be "switched off"? :-)

It's not an implicit rule. If either rule matches the FIRST time the
traffic is seen, it will become an established connection. NAT will be
applied to it in both directions. See the current list of tracked
connections with:

cat /proc/net/ip_conntrack

Don't run that on a system with a lot of traffic. You'll get one line for
each session. For 1000 sessions, that's manageable. For 500,000, it will
block the terminal for a long time.

Regards,
Tyler

-- 
"The map is not the territory."
   -- Alfred Korzybski

Re:

[Jan Engelhardt]

On Tuesday 2011-08-23 13:35, Tyler J. Wagner wrote:

>On 2011-08-23 12:08, Ellad Yatsko wrote:
>> Main problem is DNAT does not work as I wait. It seems to me there is an
>> implicit additional
>> DNAT rule for SNAT, and because *my* DNAT rule does not work. May you show
>> me how it
>> could be "switched off"? :-)
>
>It's not an implicit rule. If either rule matches the FIRST time the
>traffic is seen, it will become an established connection. NAT will be
>applied to it in both directions. See the current list of tracked
>connections with:
>
>cat /proc/net/ip_conntrack
>
>Don't run that on a system with a lot of traffic. You'll get one line for
>each session. For 1000 sessions, that's manageable. For 500,000, it will
>block the terminal for a long time.

That's why one normally uses conntrack -L | less so that that does not 
happen.

Re:

[Tyler J. Wagner]

On 2011-08-24 08:35, Jan Engelhardt wrote:
>> Don't run that on a system with a lot of traffic. You'll get one line for
>> each session. For 1000 sessions, that's manageable. For 500,000, it will
>> block the terminal for a long time.
> 
> That's why one normally uses conntrack -L | less so that that does not 
> happen.

Unfortunately, conntrack isn't installed by default on a lot of
distributions. Just "less /proc/..." will do the same.

Regards,
Tyler

-- 
"Religion is the opiate of the masses, so long as the masses are straight.
However, amass a bunch of lesbians and you're going to need actual drugs."
   -- OKCupid Blog, with apologies to Karl Marx
      http://blog.okcupid.com/index.php/gay-sex-vs-straight-sex/

(unknown)

[Alberto Díez]

hi!
 
 I am trying to make use of a large number of rules
 with iptables. 
 
 I have seen there are some optimizations referenced
 like nf-HiPAC (www.hipac.org) , iptables with
 classifiers (www.geocities.com/hamidreza_jm) which
 appearently can deal with thousands of rules (thats
 what i need).
 
 I want per flow (orig addr,dst addr, orig port, dst
 port, proto) filtering thats why i don´t think i can
 use ipsets (or can i?)
 I also would like to have the nice iptables features
 like  mangle table and counters ..
 
 I dont really understand what the conntrack does, or
 if it can somehow helpme (where is the nice
 documentation about this??)
 
 What is the netfilter preferred way to have a large
 set of rules and still do packet filtering?  are
 HiPAC, iptables with classifiers or any other
 solution
 actual?
 
 is there a howto,manual,some kind of
 documentation, all that I find about this are quite
 old (3 years?) material in the mailing list ... Is
 this problem already solved? what was the solution
 taken?
 
 
 well if you could answer any of this questions i
 would
 be very thankful
 
 Alberto Diez
 
 
      


      ______________________________________________ 
Enviado desde Correo Yahoo!
Disfruta de una bandeja de entrada más inteligente. http://es.docs.yahoo.com/mail/overview/index.html

RE:

[Rob Sterenborg]

>  I dont really understand what the conntrack does, or
>  if it can somehow helpme (where is the nice
>  documentation about this??)

http://iptables-tutorial.frozentux.net/iptables-tutorial.html#STATEMACHI
NE


Grts,
Rob

(unknown),

[Joe Ruddy]

Hello,

We are moving to a Co-Location center and will need to forward all traffic
for all our IP to our new IP addresses.

As an example our block is 12.24.15.0/24

Our new block will be 54.64.18.0/24

If we have a webserver at 12.24.15.24 I would like all requests to
12.24.15.24 to be forwarded to 54.64.18.24 where the new machine will be
located.
If we have a mailserver at 12.24.15.19 I would like all requests to
12.24.15.19 to be forwarded to 54.64.18.19 where the new machine will be
located.

I add one rule ..."iptables -t nat -A PREROUTING -d 12.24.15.24 -j DNAT --to
54.64.18.24"

If I try to ssh or go to the website hosted there I get nothing.  I can see
that the requests arrive at 54.64.18.24 by looking at the logs.

Any ideas?

Thanks

Joe

Joe Ruddy
Director of Technology
Novapointe LLC
909-930-3062 x2738
jruddy@novapointe.com 

Re:

[Martijn Lievaart]

Joe Ruddy wrote:
> Hello,
>
> We are moving to a Co-Location center and will need to forward all traffic
> for all our IP to our new IP addresses.
>
> As an example our block is 12.24.15.0/24
>
> Our new block will be 54.64.18.0/24
>
> If we have a webserver at 12.24.15.24 I would like all requests to
> 12.24.15.24 to be forwarded to 54.64.18.24 where the new machine will be
> located.
> If we have a mailserver at 12.24.15.19 I would like all requests to
> 12.24.15.19 to be forwarded to 54.64.18.19 where the new machine will be
> located.
>
> I add one rule ..."iptables -t nat -A PREROUTING -d 12.24.15.24 -j DNAT --to
> 54.64.18.24"
>
> If I try to ssh or go to the website hosted there I get nothing.  I can see
> that the requests arrive at 54.64.18.24 by looking at the logs.
>
>   

It does not work because the return traffic is not seen by the old 
firewall so it's not properly de-dnatted. Nat only works if the firewall 
sees all the traffic, not only one side of it.

Here's one way to get around it.

- Set up a tunnel between the firewall at the old location and the 
firewall at the new location.
- Give the colo a second subnet on the same physical network, say 
192.168.15.0/24
- On the old firewall:
  - add a route for 192.168.15.0/24 into the tunnel
  - Dnat all requests on the old firewall for 12.24.15.x to 192.168.15.x
- On the new firewall:
  - Use source routing to route all trafic FROM 192.168.15.0/24 into the 
tunnel.

A simpler way would be to use rinetd to reroute all requests to the new 
servers, but this looses the original source address. If you don't mind 
your logs becomming virtually useless, this is much simpler.

A final trick would be to use something that can do stateless nat out to 
the same interface that the packet was received on. I don't know of any 
device that can do this, but I don't know very much about this. Then you 
use stateless nat on the old and the new location, on the old location 
you dnat to the final destination and on the new location you snat the 
return trafic back to the original destination. This does depend on your 
new provider not doing any filtering.

May I use this to advocate the use of DNS? When moving over, you set the 
TTLs to 0 some time beforehand. When you move over, you update the DNS 
records and the transition is instant. Don't forget to reset the TTL to 
some sane value after you have convinced yourself everything works.

If all of the above is Chinese to you, I suggest you forget the whole 
idea and deal with the problem differently, mainly by telling all 
clients the new IP.

HTH,
M4