Bridge Transparent Proxy

Bridge Transparent Proxy

[Jon Tim]

HI Expert,
 
Please allow me to ask bridge transparent proxy.
 
I have public iP address 203.X.X.X and I used Bridge
between Wireless LAN access point and HUB. So, all IP
are in 203.X.X.X with same subnet mask 255.255.255.0.
 
Interenet---------->
eth0------>bridge<------eth1<--------WirlessAP
 
Bridge is working well with 2 NICs. 
 
My question is I would like to forward only port 80
and 443  from eth1 to eth0 and would like to log http
traffic pass through bridge.
 
Please let me know which command to type in iptables.
 
Best regards,
Jon


       
____________________________________________________________________________________Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

Re: Bridge Transparent Proxy

[Robert LeBlanc]

You will need to look at ebtables. Bridging will bypass iptables. Ebtables
is much like iptables, but there are some subtle differences that may choke
you up. Haven't worked much with it though.

Robert


On 5/22/07 8:28 AM, "Jon Tim" <lcguy229@yahoo.com> wrote:

> HI Expert,
>  
> Please allow me to ask bridge transparent proxy.
>  
> I have public iP address 203.X.X.X and I used Bridge
> between Wireless LAN access point and HUB. So, all IP
> are in 203.X.X.X with same subnet mask 255.255.255.0.
>  
> Interenet---------->
> eth0------>bridge<------eth1<--------WirlessAP
>  
> Bridge is working well with 2 NICs.
>  
> My question is I would like to forward only port 80
> and 443  from eth1 to eth0 and would like to log http
> traffic pass through bridge.
>  
> Please let me know which command to type in iptables.
>  
> Best regards,
> Jon
> 
> 
>        
> ______________________________________________________________________________
> ______Get the Yahoo! toolbar and be alerted to new email wherever you're
> surfing.
> http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
> 

 
Robert LeBlanc
BioAg Computer Support
Brigham Young University
leblanc@byu.edu
(801)422-1882

Re: Bridge Transparent Proxy

[Pascal Hambourg]

Hello,

Robert LeBlanc a écrit :
> You will need to look at ebtables. Bridging will bypass iptables.

Bridged IPv4 packets traverse the iptables chains if the kernel was 
compiled with Netfilter bridge support (CONFIG_BRIDGE_NETFILTER=y). It 
allows finer filtering than ebtables, for instance accepting only 
outgoing HTTP/HTTPS connections and related ICMP messages in both 
directions thanks to connection tracking, e.g. :

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m physdev --physdev-in eth1 -m state --state NEW \
   -p tcp -m multiport --dports 80,443 -j ACCEPT

Re: Bridge Transparent Proxy

[Jon Tim]

Hello,

Many thanks for all reply to my Bridge Transparent
Proxy post.

But, please let me know more how to enable "netfilter
Bridge Support" in kernel. Can I add a linke
CONFIG_BRIDGE_NETFILTER=y" in /etc/sysctl.conf ??

And, in the second iptables command what is physdev
and physdev-in?? Does this mean physdev= eth0 and
physdev-in = eth1??

Sorry for my quetion. I am newbie in iptables and
don't understand very well?

My another qutesion is, do I need to use NAT command
in iptables? As I have all public address and why I
have to use NAT to redirect?

Jon.



--- Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
wrote:

> Hello,
> 
> Robert LeBlanc a écrit :
> > You will need to look at ebtables. Bridging will
> bypass iptables.
> 
> Bridged IPv4 packets traverse the iptables chains if
> the kernel was 
> compiled with Netfilter bridge support
> (CONFIG_BRIDGE_NETFILTER=y). It 
> allows finer filtering than ebtables, for instance
> accepting only 
> outgoing HTTP/HTTPS connections and related ICMP
> messages in both 
> directions thanks to connection tracking, e.g. :
> 
> iptables -A FORWARD -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -m physdev --physdev-in eth1 -m
> state --state NEW \
>    -p tcp -m multiport --dports 80,443 -j ACCEPT
> 
> 



       
____________________________________________________________________________________Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

Re: Bridge Transparent Proxy

[Gáspár Lajos]

Jon Tim írta:
> Hello,
>
> Many thanks for all reply to my Bridge Transparent
> Proxy post.
>
> But, please let me know more how to enable "netfilter
> Bridge Support" in kernel. Can I add a linke
> CONFIG_BRIDGE_NETFILTER=y" in /etc/sysctl.conf ??
>
>   
No. This is an option in your kernel config.
Search the net about building a kernel.
> And, in the second iptables command what is physdev
> and physdev-in?? Does this mean physdev= eth0 and
> physdev-in = eth1??
>   
man iptables

-m physdev => iptables will use the physdev module (-m)
--physdev-in eth1 => the incoming (physical) device is eth1
> Sorry for my quetion. I am newbie in iptables and
> don't understand very well?
>
> My another qutesion is, do I need to use NAT command
> in iptables? As I have all public address and why I
> have to use NAT to redirect?
>   
NAT and REDIRECT is mainly to support a firewalled network or change the 
source/destination of a connection.
> Jon.
>
>   
Swifty

Re: Bridge Transparent Proxy

[Grant Taylor]

On 05/22/07 09:35, Robert LeBlanc wrote:
> You will need to look at ebtables. Bridging will bypass iptables. Ebtables
> is much like iptables, but there are some subtle differences that may choke
> you up. Haven't worked much with it though.

You can configure the kernel to apply IPTables Net Filters (Layer 3) to 
EBTables bridged (Layer 2) traffic.

To quote the (2.6.8.1) kernel source:
"""
CONFIG_BRIDGE_NETFILTER - Enabling this option will let arptables resp. 
iptables see bridged ARP resp. IP traffic. If you want a bridging 
firewall, you probably want this option enabled.

Enabling or disabling this option doesn't enable or disable ebtables.
"""




Grant. . . .

Re: Bridge Transparent Proxy

[Robert LeBlanc]

On 5/22/07 10:09 AM, "Grant Taylor" <gtaylor@riverviewtech.net> wrote:

> On 05/22/07 09:35, Robert LeBlanc wrote:
>> You will need to look at ebtables. Bridging will bypass iptables. Ebtables
>> is much like iptables, but there are some subtle differences that may choke
>> you up. Haven't worked much with it though.
> 
> You can configure the kernel to apply IPTables Net Filters (Layer 3) to
> EBTables bridged (Layer 2) traffic.
> 
> To quote the (2.6.8.1) kernel source:
> """
> CONFIG_BRIDGE_NETFILTER - Enabling this option will let arptables resp.
> iptables see bridged ARP resp. IP traffic. If you want a bridging
> firewall, you probably want this option enabled.
> 
> Enabling or disabling this option doesn't enable or disable ebtables.
> """
> 
> 
> 
> 
> Grant. . . .
> 

Thanks, I wasn't aware of this option as I haven't done much with bridging
since I had lots of trouble with trying to bridge and NAT on the same
network (use allow the same physical network after my linux gateway to carry
my public network and the NATed private network). I will have to look into
it again, this option may have been a cause of some of my issues.

 
Robert LeBlanc
BioAg Computer Support
Brigham Young University
leblanc@byu.edu
(801)422-1882

Re: Bridge Transparent Proxy

[Grant Taylor]

On 05/22/07 12:07, Robert LeBlanc wrote:
> Thanks, I wasn't aware of this option as I haven't done much with 
> bridging since I had lots of trouble with trying to bridge and NAT on 
> the same network (use allow the same physical network after my linux 
> gateway to carry my public network and the NATed private network). I 
> will have to look into it again, this option may have been a cause of 
> some of my issues.

*nod*  Bridging Routers can be interesting critters to work with.

Brouters are usually used to allow globally routable systems IP 
addresses to be used in front of and behind a firewall (of sorts).  I.e. 
a small block of IP addresses that the brouter uses for its external IP 
address as well as internal public servers use IP addresses from to be 
directly accessible from the net with out any sort of NAT.

(INet) --- (Cable / DSL modem) --- (BRouter) --- (Server(s)
                                              --- (Workstation(s))

To pull this off usually you bridge the internal and external NICs 
together and multi home the bridge interface for your internal and 
external IP addresses.  I.e. bri0 = A.B.C.D and bri0:1 = 192.168.144.254 
are your IP addresses.

In this case, you only bridge traffic to / from the A.B.C.x network and 
route any thing else.  You can even serve DHCP on the internal LAN with 
out a problem.

In this scenario, you can use either EBTables or IPTables to do your 
filtering.  The only thing you need to remember is to not bridge (DROP 
in the brouting table / BROUTE chain) any internal traffic and force it 
to be routed.  Another way to say it is to only bridge traffic to / from 
your globally routable IP addresses.  Remember that you will need to 
pass some ARP traffic too.




Grant. . . .

Re: Bridge Transparent Proxy

[Pascal Hambourg]

Grant Taylor a écrit :
> 
> Brouters are usually used to allow globally routable systems IP 
> addresses to be used in front of and behind a firewall (of sorts).  I.e. 
> a small block of IP addresses that the brouter uses for its external IP 
> address as well as internal public servers use IP addresses from to be 
> directly accessible from the net with out any sort of NAT.

I'm curious : why is a bridge needed for this ? Doesn't a simple router 
do the job as well ?

Re: Bridge Transparent Proxy

[Grant Taylor]

On 05/22/07 13:36, Pascal Hambourg wrote:
> I'm curious : why is a bridge needed for this ? Doesn't a simple router 
> do the job as well ?

No.

Let me re-layout the network including IP addresses.

(INet [A.B.C.Z]) --- (BRouter [A.B.C.D]) --- ([A.B.C.E] Server(s)
                        [192.168.144.254] --- ([192.168.144.1-100])

Here you can see that you have the same subnet of A.B.C.x on both sides 
of the bridging router.  There is no good (read easy) way to have the 
same subnet on multiple sides of a router short of double natting which 
in and of its self is not easy to do on a singular box.

So what you do is bridge the A.B.C.x traffic to both networks and route 
the other subnet(s) as needed.

Does this help?



Grant. . . .

NAT addresses - RFC or tradition?

[Paul Blondé]

I've noticed that a lot of people use the 192.168.X.X subnet for internal
networks, is this (and the less-used 10-series) a requirement of some RFC,
or a recommendation that has become tradition?

We are using a completely different subnet, something similar to (for
example) 42.127.129.X to further obfuscate the internal network from
outside. This, and many other examples, produces a class-A subnet mask (some
produce a class-B) when entered in WinXP's TCP/IP dialog, although the
actual mask we use with it is class-C.

Is this a no-no? Will it break our server's IPTables when communicating with
it? Am I in for a lot of trouble? The addresses don't seem to cause any
problems, but I don't want this to jump up and bite us in the bottom
sometime down the road.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Blondé

Re: NAT addresses - RFC or tradition?

[Andre Guimarães]

It's quite simple.
You're using public IPs in your internal networks.
Some of these IPs may exist and have an owner an maybe even a web site.
You'll be in trouble in the day you wish to acess one of these IPs on the 
internet because you won't reach them because you have them on your network 
and so won't route the packets to the internet.

The IP's in fact, don't have any thing different, so you can use them and 
iptables will not have any problems. It's just a route problem, that as you 
chose to use these IP's, you won't be able to reach these real public IP's in 
the internet.

Sorry for the bad english.

On Tuesday 22 May 2007 16:26, Paul Blondé wrote:
> I've noticed that a lot of people use the 192.168.X.X subnet for internal
> networks, is this (and the less-used 10-series) a requirement of some RFC,
> or a recommendation that has become tradition?
>
> We are using a completely different subnet, something similar to (for
> example) 42.127.129.X to further obfuscate the internal network from
> outside. This, and many other examples, produces a class-A subnet mask
> (some produce a class-B) when entered in WinXP's TCP/IP dialog, although
> the actual mask we use with it is class-C.
>
> Is this a no-no? Will it break our server's IPTables when communicating
> with it? Am I in for a lot of trouble? The addresses don't seem to cause
> any problems, but I don't want this to jump up and bite us in the bottom
> sometime down the road.
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Paul Blondé

-- 
André Guimarães
Databras Informática
Matriz RJ - 55 (21) 2518-2363
Filial ES - 55 (27) 3233-0098
http://www.databras.com.br

Re: NAT addresses - RFC or tradition?

[Tim Evans]

On Tue, 22 May 2007 16:46:25 -0300, Andre Guimarães wrote
> It's quite simple.
> You're using public IPs in your internal networks.
> Some of these IPs may exist and have an owner an maybe even a web site.
> You'll be in trouble in the day you wish to acess one of these IPs 
> on the internet because you won't reach them because you have them 
> on your network and so won't route the packets to the internet.

In other words, the RFC addresses are specifically for use in internal
networks, since they are guaranteed not to be used on the public internet, and
not routed to by any public internet router.
--
Tim Evans, TKEvans.com, Inc.    |    5 Chestnut Court
tkevans@tkevans.com             |    Owings Mills, MD 21117
http://www.tkevans.com/         |    443-394-3864
http://www.come-here.com/News/  |

Re: NAT addresses - RFC or tradition?

[Marius-Iulian Corici]

rfc 1918
Tim Evans wrote:
> On Tue, 22 May 2007 16:46:25 -0300, Andre Guimarães wrote
>   
>> It's quite simple.
>> You're using public IPs in your internal networks.
>> Some of these IPs may exist and have an owner an maybe even a web site.
>> You'll be in trouble in the day you wish to acess one of these IPs 
>> on the internet because you won't reach them because you have them 
>> on your network and so won't route the packets to the internet.
>>     
>
> In other words, the RFC addresses are specifically for use in internal
> networks, since they are guaranteed not to be used on the public internet, and
> not routed to by any public internet router.
> --
> Tim Evans, TKEvans.com, Inc.    |    5 Chestnut Court
> tkevans@tkevans.com             |    Owings Mills, MD 21117
> http://www.tkevans.com/         |    443-394-3864
> http://www.come-here.com/News/  |
>
>
>   

Re: NAT addresses - RFC or tradition?

[R. DuFresne]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1413 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 22 May 2007, Tim Evans wrote:

> On Tue, 22 May 2007 16:46:25 -0300, Andre Guimarães wrote
>> It's quite simple.
>> You're using public IPs in your internal networks.
>> Some of these IPs may exist and have an owner an maybe even a web site.
>> You'll be in trouble in the day you wish to acess one of these IPs
>> on the internet because you won't reach them because you have them
>> on your network and so won't route the packets to the internet.
>
> In other words, the RFC addresses are specifically for use in internal
> networks, since they are guaranteed not to be used on the public internet, and
> not routed to by any public internet router.


"should not" be publically routed, there are itiots out there in the 
world, one can't fix stupid.

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFGdsCGst+vzJSwZikRAvYIAJ0fFaAVU0xlLtkL6S4XJqEZcYrlMgCcDEf3
qsBjsVnL0PyYWgl5ingpEPw=
=IssI
-----END PGP SIGNATURE-----

Re: NAT addresses - RFC or tradition?

[R. DuFresne]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2896 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Stealing another companies or organizations IP addresses can well break 
thing for you like SMTP, and web sites you host.  In a small network, 
these things can be fixed quite  easily, yet requires a trip to each and 
every wrongly numbers system.  In a large network this can be quite an 
extensive issue when trying to come into compliance with the real world. 
BTDT.  The proper thing to do, is to get a IP space block from your 
provider for at the least external addressing and use proper RFC assigned 
private addresses for NAT functioning internally, it saves many headaches 
down the road.

Thanks,

Ron DuFresne

On Tue, 22 May 2007, Andre Guimarães wrote:

> It's quite simple.
> You're using public IPs in your internal networks.
> Some of these IPs may exist and have an owner an maybe even a web site.
> You'll be in trouble in the day you wish to acess one of these IPs on the
> internet because you won't reach them because you have them on your network
> and so won't route the packets to the internet.
>
> The IP's in fact, don't have any thing different, so you can use them and
> iptables will not have any problems. It's just a route problem, that as you
> chose to use these IP's, you won't be able to reach these real public IP's in
> the internet.
>
> Sorry for the bad english.
>
> On Tuesday 22 May 2007 16:26, Paul Blondé wrote:
>> I've noticed that a lot of people use the 192.168.X.X subnet for internal
>> networks, is this (and the less-used 10-series) a requirement of some RFC,
>> or a recommendation that has become tradition?
>>
>> We are using a completely different subnet, something similar to (for
>> example) 42.127.129.X to further obfuscate the internal network from
>> outside. This, and many other examples, produces a class-A subnet mask
>> (some produce a class-B) when entered in WinXP's TCP/IP dialog, although
>> the actual mask we use with it is class-C.
>>
>> Is this a no-no? Will it break our server's IPTables when communicating
>> with it? Am I in for a lot of trouble? The addresses don't seem to cause
>> any problems, but I don't want this to jump up and bite us in the bottom
>> sometime down the road.
>>
>>
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Paul Blondé
>
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFGdsAgst+vzJSwZikRAvKcAJ9gc5ZLSh++4Yu553m8dETiPZicqgCfYER9
MADqb7HjfwQWHxAOyJfu/us=
=DJrm
-----END PGP SIGNATURE-----

Re: NAT addresses - RFC or tradition?

[Leonardo Rodrigues Magalhães]

Paul Blondé escreveu:
> I've noticed that a lot of people use the 192.168.X.X subnet for internal
> networks, is this (and the less-used 10-series) a requirement of some RFC,
> or a recommendation that has become tradition?
>
> We are using a completely different subnet, something similar to (for
> example) 42.127.129.X to further obfuscate the internal network from
> outside. This, and many other examples, produces a class-A subnet mask (some
> produce a class-B) when entered in WinXP's TCP/IP dialog, although the
> actual mask we use with it is class-C.
>
> Is this a no-no? Will it break our server's IPTables when communicating with
> it? Am I in for a lot of trouble? The addresses don't seem to cause any
> problems, but I don't want this to jump up and bite us in the bottom
> sometime down the road.
>   

    Yes, those 'reserved' IP addresses are declared by RFC 1918. Please 
check:

http://tools.ietf.org/html/rfc1918
http://en.wikipedia.org/wiki/Private_network

    Your network will work with no problems, except if you had to access 
some far-far-far away network which uses your local addresses, which 
should never be used as local ones.

   

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: NAT addresses - RFC or tradition?

[Grant Taylor]

On 05/22/07 14:26, Paul Blondé wrote:
> I've noticed that a lot of people use the 192.168.X.X subnet for 
> internal networks, is this (and the less-used 10-series) a 
> requirement of some RFC, or a recommendation that has become 
> tradition?

10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and 
192.168.0.0-192.168.255.255 are reserved for private (read internal) use 
and guaranteed to not be globally routable.  As others have stated, you 
can use any address you want, though you run the risk of being in 
conflict with some subnet somewhere.  Granted it is VERY unlikely that 
you will effect any one other than your self as the world will route to 
the other subnet, not you.

Please reference RFC 3330 - "Special-Use IPv4 Addresses" 
(http://www.rfc-editor.org/rfc/rfc3330.txt) for more information on 
these and other reserved subnets.

> We are using a completely different subnet, something similar to (for 
> example) 42.127.129.X to further obfuscate the internal network from 
> outside. This, and many other examples, produces a class-A subnet 
> mask (some produce a class-B) when entered in WinXP's TCP/IP dialog, 
> although the actual mask we use with it is class-C.

*nod*

> Is this a no-no? Will it break our server's IPTables when 
> communicating with it? Am I in for a lot of trouble? The addresses 
> don't seem to cause any problems, but I don't want this to jump up 
> and bite us in the bottom sometime down the road.

Well, the 42.x.y.z is not too bad as far as conflicting with someone 
else seeing as how IANA has it "Reserved".  Take a look at the "Internet 
Protocol v4 Address Space" page 
(http://www.iana.org/assignments/ipv4-address-space) on IANA's web site 
for more information.



Grant. . . .

Re: Bridge Transparent Proxy

[Petr Pisar]

On 2007-05-22, Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 05/22/07 13:36, Pascal Hambourg wrote:
>> I'm curious : why is a bridge needed for this ? Doesn't a simple router 
>> do the job as well ?
>
> No.
>
> Let me re-layout the network including IP addresses.
>
> (INet [A.B.C.Z]) --- (BRouter [A.B.C.D]) --- ([A.B.C.E] Server(s)
>                         [192.168.144.254] --- ([192.168.144.1-100])
>
> Here you can see that you have the same subnet of A.B.C.x on both sides 
> of the bridging router.  There is no good (read easy) way to have the 
> same subnet on multiple sides of a router short of double natting which 
> in and of its self is not easy to do on a singular box.
>
> So what you do is bridge the A.B.C.x traffic to both networks and route 
> the other subnet(s) as needed.
>
Or you switch on arp proxy on the public interface of router ;)

-- Petr

Re: Bridge Transparent Proxy

[Pascal Hambourg]

Grant Taylor a écrit :
> 
> Let me re-layout the network including IP addresses.
> 
> (INet [A.B.C.Z]) --- (BRouter [A.B.C.D]) --- ([A.B.C.E] Server(s)
>                        [192.168.144.254] --- ([192.168.144.1-100])
> 
> Here you can see that you have the same subnet of A.B.C.x on both sides 
> of the bridging router.

Now I see. But wouldn't it be worth subnetting A.B.C.x ?

>  There is no good (read easy) way to have the 
> same subnet on multiple sides of a router

Do you mean that ARP proxy would not be a good way ? Ok, I guess it 
would disrupt IP broadcasts a bit...

> short of double natting which 
> in and of its self is not easy to do on a singular box.

Anyway NAT is evil. Don't use unless you can't avoid it.

Re: Bridge Transparent Proxy

[Grant Taylor]

On 5/22/2007 5:07 PM, Pascal Hambourg wrote:
> Now I see. But wouldn't it be worth subnetting A.B.C.x ?

If you have the option, yes.  However, that is seldom an option, even 
less so with out the providers support.

Consider a cable modem / DSL install where you get 4 IP addresses, 
having nothing to do with subnets.  I.e. .62, .63, .64, and .65.  You 
can not do any viable subnetting with this.

Even if you can viably do subnetting, you have to have the provider 
configure the remaining IPs available via the IP facing them.

It has been my experience that it is much easier to do BRouting in these 
cases.

> Do you mean that ARP proxy would not be a good way ? Ok, I guess it 
> would disrupt IP broadcasts a bit...

I have never actually used ARP proxy, so I can't say for sure.  However 
when I have read about ARP proxying in the past, it never sat very well 
with me.  It always seemed like it solved part of the problem but caused 
others.

> Anyway NAT is evil. Don't use unless you can't avoid it.

I'll have to disagree with you on that statement.  Now if you amend it a 
bit, I can live with it.  "NATing in the wrong locations is evil."  NAT 
in and of its self is a good tool to use.  However it is not the end 
all, be all tool that some would like it to be.  NATing a private 
network out to a single IP on the internet for outbound internet access 
is very good.  If you want to start having some inbound internet access 
it is not as good for very long.



Grant. . . .

Re: Bridge Transparent Proxy

[Robert LeBlanc]

On 5/22/07 12:30 PM, "Grant Taylor" <gtaylor@riverviewtech.net> wrote:

> On 05/22/07 12:07, Robert LeBlanc wrote:
>> Thanks, I wasn't aware of this option as I haven't done much with
>> bridging since I had lots of trouble with trying to bridge and NAT on
>> the same network (use allow the same physical network after my linux
>> gateway to carry my public network and the NATed private network). I
>> will have to look into it again, this option may have been a cause of
>> some of my issues.
> 
> *nod*  Bridging Routers can be interesting critters to work with.
> 
> Brouters are usually used to allow globally routable systems IP
> addresses to be used in front of and behind a firewall (of sorts).  I.e.
> a small block of IP addresses that the brouter uses for its external IP
> address as well as internal public servers use IP addresses from to be
> directly accessible from the net with out any sort of NAT.
> 
> (INet) --- (Cable / DSL modem) --- (BRouter) --- (Server(s)
>                                               --- (Workstation(s))
> 
> To pull this off usually you bridge the internal and external NICs
> together and multi home the bridge interface for your internal and
> external IP addresses.  I.e. bri0 = A.B.C.D and bri0:1 = 192.168.144.254
> are your IP addresses.
> 
> In this case, you only bridge traffic to / from the A.B.C.x network and
> route any thing else.  You can even serve DHCP on the internal LAN with
> out a problem.
> 
> In this scenario, you can use either EBTables or IPTables to do your
> filtering.  The only thing you need to remember is to not bridge (DROP
> in the brouting table / BROUTE chain) any internal traffic and force it
> to be routed.  Another way to say it is to only bridge traffic to / from
> your globally routable IP addresses.  Remember that you will need to
> pass some ARP traffic too.
> 
> 
> 
> 
> Grant. . . .
> 

That is what I did, I think there was a slight mis-configuration and my NAT
was dropping traffic like crazy. It would only happen after a period of time
though, no error messages that I could see. I had three separate internal
nets and the 192.168.1.x would not work, but 192.168.2.x would more then the
other one. I never did try out 192.168.3.x because I had so many issues with
the first two. I'll have to look into it again someday. I just moved my
servers out in front of my gateway for the time being.

 
Robert LeBlanc
BioAg Computer Support
Brigham Young University
leblanc@byu.edu
(801)422-1882

RE: bridge + transparent proxy

[Jason Opperisano]

> hi all , i`m running linux kernel 2.4.20 with bridge installed (2 eth).. the
> bridge works nice and i can block any traffic that i want
> the problem is i can`t do tranparent proxy , i tried using
>
> iptables -A PREROUTING -t nat -p tcp --dport 80 -j DNAT --to $myproxy:3128
>
> and it didn`t work... my bridge didn`t get any incoming traffic from client
> to port 80 or 3128....
> is it because bridge only run in layer 1 or something else ? sorry for my
> dumb question :)
> any idea ?
>
> Regards,
>
>
> Kristian

try:  http://en.tldp.org/HOWTO/TransparentProxy-7.html

and for what it's worth--bridges are layer 2.

-j

Re: bridge + transparent proxy

[ArioS]

i tried it and it seems not work.... :)
i`m googling and found this site http://ebtables.sourceforge.net/
has anyone tried this before ? maybe can share ur experience :)


Regards,


Kristian
----- Original Message -----
From: "Jason Opperisano" <Jopperisano@alphanumeric.com>
To: <netfilter@lists.netfilter.org>
Sent: Tuesday, August 24, 2004 7:28 PM
Subject: RE: bridge + transparent proxy


> hi all , i`m running linux kernel 2.4.20 with bridge installed (2 eth)..
the
> bridge works nice and i can block any traffic that i want
> the problem is i can`t do tranparent proxy , i tried using
>
> iptables -A PREROUTING -t nat -p tcp --dport 80 -j DNAT --to $myproxy:3128
>
> and it didn`t work... my bridge didn`t get any incoming traffic from
client
> to port 80 or 3128....
> is it because bridge only run in layer 1 or something else ? sorry for my
> dumb question :)
> any idea ?
>
> Regards,
>
>
> Kristian

try:  http://en.tldp.org/HOWTO/TransparentProxy-7.html

and for what it's worth--bridges are layer 2.

-j

Multiple IPSEC VPNs through a firewall based on 2.4.2X kernel

[Roksana Boreli]

Hi,

I am trying to set up multiple ipsec VPN clients working behind a Linux
router with NAT/PAT, based on a 2.4.20 (can be 2.4.22) kernel. I would
like to be able to connect a number of Windows (2k or XP) machines to an
existing Cisco VPN server. 

client 1 (ipsec) --->  | router	|
client 2 (ipsec) --->  |  NAT/	|
.		        PAT	| -> ipsec VPN server (Cisco)
.		     |		|
client 10 (ipsec) --->|		|

A patch seems to be needed to make this work, and I have seen a lot of
emails with a similar question in regards to pptp VPN clients, but
nothing encouraging for ipsec.  I have also seen the IP masquerade HOWTO
and the VPN HOWTO, which both refer to a patch for 2.2 kernels, but
claim nothing is available for 2.4 kernels. I am a netfilter newbie (if
this is not blindingly obvious), so any help would be much appreciated.


Kind regards, Roksana

Re: Multiple IPSEC VPNs through a firewall based on 2.4.2X kernel

[Ming-Ching Tiew]

> 
> I am trying to set up multiple ipsec VPN clients working behind a Linux
> router with NAT/PAT, based on a 2.4.20 (can be 2.4.22) kernel. I would
> like to be able to connect a number of Windows (2k or XP) machines to an
> existing Cisco VPN server. 
> 
> client 1 (ipsec) --->  | router |
> client 2 (ipsec) --->  |  NAT/ |
> .         PAT | -> ipsec VPN server (Cisco)
> .      | |
> client 10 (ipsec) --->| |
> 

Instead of making your VPN clients tunnel thru' Linux NAT router,
it would be better if you make the Linux NAT router perform
IPSEC VPN client functions with the Cisco ipsec VPN server 

In the configuration I mention, you are effectively putting IPSEC
behind NAT,  whereas to have IPSEC before NAT, that's a lot 
more problematic.

Re: Multiple IPSEC VPNs through a firewall based on 2.4.2X kernel

[Payal Rathod]

On Tue, Aug 24, 2004 at 01:46:45PM +0800, Ming-Ching Tiew wrote:
> Instead of making your VPN clients tunnel thru' Linux NAT router,
> it would be better if you make the Linux NAT router perform
> IPSEC VPN client functions with the Cisco ipsec VPN server 

How does one do that? Does one have to install a different software for that?

-Payal

Re: Multiple IPSEC VPNs through a firewall based on 2.4.2X kernel

[Ming-Ching Tiew]

> On Tue, Aug 24, 2004 at 01:46:45PM +0800, Ming-Ching Tiew wrote:
> > Instead of making your VPN clients tunnel thru' Linux NAT router,
> > it would be better if you make the Linux NAT router perform
> > IPSEC VPN client functions with the Cisco ipsec VPN server 
> 
> How does one do that? Does one have to install a different software for that?
> 

Redhat distributions include IPSec capabilities, though I am not too 
familiar with the versions. 

If you would like to roll your own, I recommend you use openswan -
freeswan/superfreeswan are supposed to be freezed or in slow maintainance
mode.

You must first find out if the Cisco is going to use 'Aggressive Mode'. 
Avoid using 'Aggressive Mode' if possible. If 'Aggressive mode' is 
needed you have to use openswan-1.0.7, otherwise use openswan-2.1.4 
or 2.1.5 because they patch the kernel more cleanly.

bridge + transparent proxy

[ArioS]

hi all , i`m running linux kernel 2.4.20 with bridge installed (2 eth).. the
bridge works nice and i can block any traffic that i want
the problem is i can`t do tranparent proxy , i tried using

iptables -A PREROUTING -t nat -p tcp --dport 80 -j DNAT --to $myproxy:3128

and it didn`t work... my bridge didn`t get any incoming traffic from client
to port 80 or 3128....
is it because bridge only run in layer 1 or something else ? sorry for my
dumb question :)
any idea ?

Regards,


Kristian