Rikki
asked on
[Firewall] A *real* transparent proxy anyone ??
My setup:
---------------------
Internet <--------|Linux Firewall (LF)|------> Internal
---------------------
Users on the Internet have to be able to initiate a
connection to the LF to get a service.
(Note: the users must give the IP of the LF as the
host they want to connect to)
The connection must be forwarded from the LF to a
machine on the internal network, (The real server)
The real server must know the real IP of the connecting
user. (The service in question is an SNA gateway)
On there way out, the packets must again have there
source address changed so they appear coming from the LF.
My problem:
'ipfwadm' only supports redirecting to ports on the local
machine.
'tproxy' changes the source address.
'redir' changes the source address.
'plug_gw' changes the source address.
In short: I haven't found a way to do this !
My Solution:
[This space desperately left blank]
--
Rikhardur Egilsson - Domain Administrator - Tel : +354-5695100
Armuli 2 - IS-108 Reykjavik - Iceland - Fax : +354-5695251
rikardur@skyrr.is - Skyrr Ltd - Iceland Information Management
---------------------
Internet <--------|Linux Firewall (LF)|------> Internal
---------------------
Users on the Internet have to be able to initiate a
connection to the LF to get a service.
(Note: the users must give the IP of the LF as the
host they want to connect to)
The connection must be forwarded from the LF to a
machine on the internal network, (The real server)
The real server must know the real IP of the connecting
user. (The service in question is an SNA gateway)
On there way out, the packets must again have there
source address changed so they appear coming from the LF.
My problem:
'ipfwadm' only supports redirecting to ports on the local
machine.
'tproxy' changes the source address.
'redir' changes the source address.
'plug_gw' changes the source address.
In short: I haven't found a way to do this !
My Solution:
[This space desperately left blank]
--
Rikhardur Egilsson - Domain Administrator - Tel : +354-5695100
Armuli 2 - IS-108 Reykjavik - Iceland - Fax : +354-5695251
rikardur@skyrr.is - Skyrr Ltd - Iceland Information Management
ASKER
Edited text of question
As far I know, transparent proxy works fine only for
originator - it will think it connected to real server,
while request will be redirected to other IP address,
and, possible, port.
originator - it will think it connected to real server,
while request will be redirected to other IP address,
and, possible, port.
Ipfwadm with masquerading will do most of this. It'll rewrite the packet IP addresses for you, and give transparent proxying from the inside.
If you get another package, called ipautofw, this should allow you to redirect incoming traffic to a machine inside the firewall. I haven't actually used this, so I'm not 100% sure it'll do what you're looking for, but it's worth checking - it allows forwarding of UDP (and TCP?) datagrams across the firewall.
If you get another package, called ipautofw, this should allow you to redirect incoming traffic to a machine inside the firewall. I haven't actually used this, so I'm not 100% sure it'll do what you're looking for, but it's worth checking - it allows forwarding of UDP (and TCP?) datagrams across the firewall.
I don't know if you can do this or not...
I would write an ISAPI server extension (good for NT and PWS) that would query the Linux box and ask him who is connected.
It starts up with a URL mapping.
If you don't have NT/PWS, you could also recompile Apache with code to do the same thing. I think that there might be a problem keeping track, but if you've got the source for your proxy, you can do something to handle it.
In short, this is a *REAL* project. Keep looking for something commercial.
I would write an ISAPI server extension (good for NT and PWS) that would query the Linux box and ask him who is connected.
It starts up with a URL mapping.
If you don't have NT/PWS, you could also recompile Apache with code to do the same thing. I think that there might be a problem keeping track, but if you've got the source for your proxy, you can do something to handle it.
In short, this is a *REAL* project. Keep looking for something commercial.
Better Idea:
send a string with the IP:port of the user to the http server. program the server to handle it, remove it.
boom. done.
send a string with the IP:port of the user to the http server. program the server to handle it, remove it.
boom. done.
ASKER
I think 'vinniew' answered the wrong question.. :-)
At least this answer has nothing to do with the question or
my problem.
I suggest the moderator removes this 'proposed answer' and lets
the question stand as-is.
At least this answer has nothing to do with the question or
my problem.
I suggest the moderator removes this 'proposed answer' and lets
the question stand as-is.
ASKER
Just for the record,
* There is no HTTP server involved in the problem.
* Our customers should connect to the linux firewall (LF)with
there 'tn3270' clients, such as QVS3270, IRMA or IBM's.
* The LF should act as a gateway and forward there packages
to the real server (RS) who is running an SNA gateway
(SNA gateway is a way to connect to a IBM mainframe)
* The SNA gateway needs to get the real IP of the client in the
connection.
* Nedless to say I do NOT have the source to HP's SNAplus3270
product :-(
* The packages need to have there source address changed on
there way out.
* sauron's comment is a wery good one (I'd give him a few points
for it if I knew how). It pointed me to 'ipautofw' witch is
supposed to solve exactly my problem. The only drawback is
that exactly that part of the service hasn't been implemented
prpperly (yet).
(It's the -p switch I'm talking about.)
*
* There is no HTTP server involved in the problem.
* Our customers should connect to the linux firewall (LF)with
there 'tn3270' clients, such as QVS3270, IRMA or IBM's.
* The LF should act as a gateway and forward there packages
to the real server (RS) who is running an SNA gateway
(SNA gateway is a way to connect to a IBM mainframe)
* The SNA gateway needs to get the real IP of the client in the
connection.
* Nedless to say I do NOT have the source to HP's SNAplus3270
product :-(
* The packages need to have there source address changed on
there way out.
* sauron's comment is a wery good one (I'd give him a few points
for it if I knew how). It pointed me to 'ipautofw' witch is
supposed to solve exactly my problem. The only drawback is
that exactly that part of the service hasn't been implemented
prpperly (yet).
(It's the -p switch I'm talking about.)
*
May be you can use the linux IP tunneling module ?For further details you can read the following files:<YourLinuxSrcDir>/drivers/
ASKER
According to my <MyLinuxSrcDir>/drivers/ne
The machine that is supposed to appear on my internal network
has to run the tunnel encapsulator 'tunnel.o'.
This means that our customers, would have to do it.
And I'd run the decapsulator 'ipip.o'.
Sorry, but this won't go.
I guess I'l have to read over the sources to 'ipautofw' and see what can be done.
The machine that is supposed to appear on my internal network
has to run the tunnel encapsulator 'tunnel.o'.
This means that our customers, would have to do it.
And I'd run the decapsulator 'ipip.o'.
Sorry, but this won't go.
I guess I'l have to read over the sources to 'ipautofw' and see what can be done.
ASKER
Adjusted points to 200
ASKER
Adjusted points to 201
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I thing the linux ip address translation is the best way for yourconfiguration and can preserve: - **The source address** - The destination adress - or both...also, you can translate adresses for one selection of tcp/udp/icmp ports or for all ports
ASKER
This got me into the right direction, It appears as if I were one of the first to download the IP_NAT package and therefore suffered from the early bugs that have since been corrected.
With a little help from the author I got it to work and here are a few hints as to how:
* I had to apply the patch (<typo>) mentioned on the WWW
page. (This one was easy)
* Routing is done after any changes to the package on the
inbound port (i.e. if you specify -W <inbound eth>
* Routing is done before any changes made to the package on
the outbound port ((i.e. if you specify -W <outbound eth>
* So you have to specify routing (ipfwadm -F) rules for the
packages as they are in that middle stage.
IP NAT now seems to work for me 100% of the time. I have a little problem getting Linux to route back out on the same interface. That is, I have one network "behind" me, behind one router and it can't get it to route to that router.
With a little help from the author I got it to work and here are a few hints as to how:
* I had to apply the patch (<typo>) mentioned on the WWW
page. (This one was easy)
* Routing is done after any changes to the package on the
inbound port (i.e. if you specify -W <inbound eth>
* Routing is done before any changes made to the package on
the outbound port ((i.e. if you specify -W <outbound eth>
* So you have to specify routing (ipfwadm -F) rules for the
packages as they are in that middle stage.
IP NAT now seems to work for me 100% of the time. I have a little problem getting Linux to route back out on the same interface. That is, I have one network "behind" me, behind one router and it can't get it to route to that router.
ASKER