Re:

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

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)

[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:

[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/

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.