Transparent proxy where source IP address remains unchanged -- possible?

Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

I'm new to iptables and have perhaps a naive question.

I am wondering if there is a way to configure a proxy such that packets
are redirected to a new IP address, but the *source* IP address remains
unchanged.

To illustrate: let's say we have "userbox" 10.1.1.2, "faketarget"
10.1.1.3, and "realtarget" 10.1.1.4.

Userbox initiates an ssh connection to faketarget. Faketarget routes all
packets to realtarget.

I understand how to do this while changing the source IP address. I would
run these commands on faketarget:

iptables -t nat -A PREROUTING -i eth0 -s 10.1.1.2 -d 10.1.1.3 -p tcp --dport ssh -j DNAT --to 192.168.98.4 
iptables -t nat -A POSTROUTING -o eth0 -s 10.1.1.2 -d 10.1.1.3 -j SNAT --to 10.1.1.3

Easy enough. But in this case, the connection to realtarget appears to
come from faketarget, not userbox, the originator of the ssh connection.
This is normally what you want with local NAT.

But what if I want the connection to realtarget to appear to come from
userbox.  I want faketarget to be an almost invisible middleman.  I don't
want to rewrite the source IP address, but leave it as is.  If I just
leave off the second iptables line above, however, no packets are
forwarded to realtarget at all.

Is this possible?  Am I asking the wrong question?
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org

Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

I'm new to iptables and have perhaps a naive question.

I am wondering if there is a way to configure a proxy such that packets
are redirected to a new IP address, but the *source* IP address remains
unchanged.

To illustrate: let's say we have "userbox" 10.1.1.2, "faketarget"
10.1.1.3, and "realtarget" 10.1.1.4.

Userbox initiates an ssh connection to faketarget. Faketarget routes all
packets to realtarget.

I understand how to do this while changing the source IP address. I
would run these commands on the faketarget box:

iptables -t nat -A PREROUTING -i eth0 -s 10.1.1.2 -d 10.1.1.3 \
	-p tcp --dport ssh -j DNAT --to 192.168.98.4

iptables -t nat -A POSTROUTING -o eth0 -s 10.1.1.2 -d 10.1.1.3 \
	-j SNAT --to 10.1.1.3

Easy enough. But in this case, the connection to realtarget appears to
come from faketarget, not userbox, the originator of the ssh connection.
This is normally what you want with local NAT.

But what if I want the connection to realtarget to appear to come from
userbox.  I want faketarget to be an almost invisible middleman.  I
don't want to rewrite the source IP address, but leave it as is.  If I
just leave off the second iptables line above, however, no packets are
forwarded to realtarget at all.

Is this possible?  Am I asking the wrong question?
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Jan Engelhardt]

>Subject: Transparent proxy where source IP address remains unchanged --
>    possible?

Check Balabit TPROXY. To retain the source address however, you need to patch 
the application that initiates the second part. In your case, the sshd on 
faketarget.

N.B.: Why do you want to poke on _ssh_ anyway?



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

On Thu, Aug 11, 2005 at 07:42:30AM +0200, Jan Engelhardt wrote:
> >Subject: Transparent proxy where source IP address remains unchanged --
> >    possible?
> Check Balabit TPROXY. To retain the source address however, you need to patch 
> the application that initiates the second part. In your case, the sshd on 
> faketarget.

Maybe I should explain what I'm trying to accomplish to see if this is
the right (or a possible) way to go about it.

I'm relocating a web/email/ssh server from one location to another (and
consequently to a new IP).  Since it's going to take many hours for the
IP address changes to propagate across DNS, I'd like to put a proxy box
in place at the old location that simply redirects all packets to the new
location. I would prefer for the new location to see the original source
IP address, rather than the IP address of the proxy.

Why do I need to patch sshd on faketarget? What I'm trying to do is just
send all the packets to realtarget, essentially untouched (other than the
destination IP).  I don't understand why sshd on faketarget would even be
involved...?
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Jan Engelhardt]

>Why do I need to patch sshd on faketarget? What I'm trying to do is just
>send all the packets to realtarget, essentially untouched (other than the
>destination IP).  I don't understand why sshd on faketarget would even be
>involved...?

Then just use DNAT.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

Jan Engelhardt wrote:
>>Why do I need to patch sshd on faketarget? What I'm trying to do is just
>>send all the packets to realtarget, essentially untouched (other than the
>>destination IP).  I don't understand why sshd on faketarget would even be
>>involved...?
> Then just use DNAT.

Right, that's where I started. What I'm trying to figure out is why when
I only use DNAT packets don't seem to get forwarded to the new
destination. They only show up if I also change the source IP to be the
address of the proxy.

Is this because the final destination is rejecting the packets, or the
proxy server is not actually passing them on?

I think I may not properly understand some architectural detail here.  I
am changing the destination IP in DNAT/PREROUTING.  Is there anything
else I need to do to make sure the packet is properly passed on to the
destination, where the proxy basically "disappears" as a middleman?

Adam

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Grant Taylor]

>>Then just use DNAT.

This will not work because it causes a routing triangle.  Consider the packet traversal with associated addresses here:

usrbox -> faketarget
faketarget -DNAT-> realtarget
realtarget -> userbox

What is most likely happening (verifiable via TCPDump) is that the traffic IS getting DNATed as you want.  However when the realtarget replies to the traffic it will go directly to the userbox with out being unDNATed.  Thus the source address on the reply packet is from the realtarget, a box which userbox was not talking with and thus the standard TCP/IP stack will DROP and disregard the packet.  TCPDump should see these replies coming back in.

> Right, that's where I started. What I'm trying to figure out is why when
> I only use DNAT packets don't seem to get forwarded to the new
> destination. They only show up if I also change the source IP to be the
> address of the proxy.
> 
> Is this because the final destination is rejecting the packets, or the
> proxy server is not actually passing them on?

I would bet that the final destination userbox is rejecting what it believes to be half open connections that it does not know any thing about.

> I think I may not properly understand some architectural detail here.  I
> am changing the destination IP in DNAT/PREROUTING.  Is there anything
> else I need to do to make sure the packet is properly passed on to the
> destination, where the proxy basically "disappears" as a middleman?

Is the faketarget and realtarget on the same subnet or are they on different subnets?  The reason that I ask is if you could make the traffic returning from realtarget back to userbox pass through faketarget it could be unDNATed and then sent back to the userbox.  However to pull this off you would have to play with the routing on the realtarget to make it use faketarget as it's upstream gateway and then do postrouting SNATing of the source IP back to that of the faketarget as the traffic left the faketarget.  This same idea can be expanded upon if the faketarget and realtarget are not on the same subnet, but it is not easy.



Grant. . . .

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

Grant Taylor wrote:
> Is the faketarget and realtarget on the same subnet or are they on
> different subnets?  The reason that I ask is if you could make the
> traffic returning from realtarget back to userbox pass through
> faketarget it could be unDNATed and then sent back to the userbox. 
> However to pull this off you would have to play with the routing on the
> realtarget to make it use faketarget as it's upstream gateway and then
> do postrouting SNATing of the source IP back to that of the faketarget
> as the traffic left the faketarget.  This same idea can be expanded upon
> if the faketarget and realtarget are not on the same subnet, but it is
> not easy.

Different subnets.

Another complication is that some of the packets coming into realtarget
will be coming in directly from their original source, so I couldn't
just route *all* traffic back through faketarget.

But is there some way I could tag packets coming in from faketarget, so
that realtarget knows that all traffic returning back with that tag goes
through faketarget?
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

RE: Transparent proxy where source IP address remains unchanged -- possible?

[Gielen, Casper]

> >Subject: Transparent proxy where source IP address remains unchanged --
> >    possible?
> 
> Check Balabit TPROXY. To retain the source address however, you need to patch 
> the application that initiates the second part. In your case, the sshd on 
> faketarget.

I used this today with squid, and I have to say it works great.
-- 
Casper

Re: Transparent proxy where source IP address remains unchanged -- possible?

[curby .]

On 8/10/05, Adam Rosi-Kessel <adam@rosi-kessel.org> wrote:
> I'm new to iptables and have perhaps a naive question.
> 
> I am wondering if there is a way to configure a proxy such that packets
> are redirected to a new IP address, but the *source* IP address remains
> unchanged.
> 
> To illustrate: let's say we have "userbox" 10.1.1.2, "faketarget"
> 10.1.1.3, and "realtarget" 10.1.1.4.
> 
> Userbox initiates an ssh connection to faketarget. Faketarget routes all
> packets to realtarget.

This is classic Destination NAT, or "port forwarding" and is certainly possible.

> iptables -t nat -A PREROUTING -i eth0 -s 10.1.1.2 -d 10.1.1.3 \
>         -p tcp --dport ssh -j DNAT --to 192.168.98.4

In your hypothetical above, all three hosts were on the same subnet. 
If in fact your realtarget is on another subnet (as it is in this
command), then all you need is DNAT and your source address/port will
be kept.  If all three hosts are on the same network, or the source
and realtarget are on the same network, then you will need a SNAT rule
as shown here:

http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

> iptables -t nat -A POSTROUTING -o eth0 -s 10.1.1.2 -d 10.1.1.3 \
>         -j SNAT --to 10.1.1.3
> 
> Easy enough. But in this case, the connection to realtarget appears to
> come from faketarget, not userbox, the originator of the ssh connection.

Right, using the SNAT target you have mangled the packet to claim to
come from faketarget.  You shouldn't expect realtarget to see anything
different.

> This is normally what you want with local NAT.

> But what if I want the connection to realtarget to appear to come from
> userbox.  I want faketarget to be an almost invisible middleman.  I
> don't want to rewrite the source IP address, but leave it as is.  If I
> just leave off the second iptables line above, however, no packets are
> forwarded to realtarget at all.

A single line to DNAT is all that should be necessary for DNAT between
different subnets (as long as your FORWARD chain allows it).  SNAT is
definitely not required to get it to work.  If it doesn't work, likely
you have a bad setup somewhere.  HOWTO might help:

http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-6.html#ss6.2

> Is this possible?  Am I asking the wrong question?

You didn't say why you're doing this, or what else your firewall setup
has.  If it's for auditing/eavesdropping, there are certainly other
ways to do it.  If all three hosts are on the same network, the client
could simply go directly to realserver.

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

Thanks for your response:

curby . wrote:
>> iptables -t nat -A PREROUTING -i eth0 -s 10.1.1.2 -d 10.1.1.3 \
>>         -p tcp --dport ssh -j DNAT --to 192.168.98.4
> In your hypothetical above, all three hosts were on the same subnet. 
> If in fact your realtarget is on another subnet (as it is in this
> command), then all you need is DNAT and your source address/port will
> be kept.  If all three hosts are on the same network, or the source
> and realtarget are on the same network, then you will need a SNAT rule
> as shown here:

In reality, userbox, faketarget, and realtarget, are all on different
subnets.

> A single line to DNAT is all that should be necessary for DNAT between
> different subnets (as long as your FORWARD chain allows it).  SNAT is
> definitely not required to get it to work.  If it doesn't work, likely
> you have a bad setup somewhere.  HOWTO might help:

Based on other messages in this thread, it appears that the problem is
that reply packets are going directly back to userbox rather than
through faketarget and thus are being dropped.  I guess the proxy needs
to go both ways, but also be invisible. This is what I'm having trouble
figuring out.

>> Is this possible?  Am I asking the wrong question?
> You didn't say why you're doing this, or what else your firewall setup
> has.  If it's for auditing/eavesdropping, there are certainly other
> ways to do it.  If all three hosts are on the same network, the client
> could simply go directly to realserver.

The main purpose is to facility relocation of a server to a new subnet
with zero downtime while DNS changes propagate. Any client that is still
getting the old IP address should be transparently routed to the new one.
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Grant Taylor]

> Different subnets.

Hmm, this complicates things.  I will have to think on how to accomplish this on different subnets.  I would look in to the possibility of tunneling.  I think you would need to establish an IP-in-IP or GRE tunnel between the fake target and the real target so that you could pass traffic back and forth with out worrying about some intermediary router deciding that there is a better route for the traffic to take back to the original source system thus breaking the unDNATing that would be done by the fake target.

> Another complication is that some of the packets coming into realtarget
> will be coming in directly from their original source, so I couldn't
> just route *all* traffic back through faketarget.

*nod*  Yes this does complicate things.

> But is there some way I could tag packets coming in from faketarget, so
> that realtarget knows that all traffic returning back with that tag goes
> through faketarget?

Possibly.  Is the traffic in question traffic that is destined to a particular service or set of services or is the traffic just random port traffic directed at the faketarget?  If it is the former you could do the old ""Up and Over (and down) trick.  I mean you could DNAT the fraffic that was originaly destined to 22 to a different port on the realtarget thus allowing the realtarget to be inteligent in how it handled the traffic.  Namely realtarget would have to DNAT the traffic back down to it's original port (known by the fact that we are only DNATing traffic that was destined to the particular port in the first place) and MARK the connections.  This MARK value could then be used by an ip route rule on the real target to decide which routing table to use.

However if you use a tunnel to connect the fake target to the real target you would not need to do the up and over trick as you could just decide what to do / how to mark the packets based on which interface they came in to.  Then you are back to the mark value to decide which routing table to use to route the traffic correctly.



Grant. . . .

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

On Sat, Aug 13, 2005 at 01:40:57AM -0500, Grant Taylor wrote:
> Hmm, this complicates things.  I will have to think on how to accomplish 
> this on different subnets.  I would look in to the possibility of 
> tunneling.  I think you would need to establish an IP-in-IP or GRE tunnel 
> between the fake target and the real target so that you could pass traffic 
> back and forth with out worrying about some intermediary router deciding 
> that there is a better route for the traffic to take back to the original 
> source system thus breaking the unDNATing that would be done by the fake 
> target.

Interesting. Are there any pre-packaged ways to do this? This sounds like
perhaps the least complex solution, once it's actually implemented.

> >But is there some way I could tag packets coming in from faketarget, so
> >that realtarget knows that all traffic returning back with that tag goes
> >through faketarget?
> Possibly.  Is the traffic in question traffic that is destined to a 
> particular service or set of services or is the traffic just random port 
> traffic directed at the faketarget?  If it is the former you could do the 
> old ""Up and Over (and down) trick.  I mean you could DNAT the fraffic that 
> was originaly destined to 22 to a different port on the realtarget thus 
> allowing the realtarget to be inteligent in how it handled the traffic.  
> Namely realtarget would have to DNAT the traffic back down to it's original 
> port (known by the fact that we are only DNATing traffic that was destined 
> to the particular port in the first place) and MARK the connections.  This 
> MARK value could then be used by an ip route rule on the real target to 
> decide which routing table to use.

That could work. I'm really only worried about DNS, HTTP, HTTPS, SMTP,
POP3, IMAP, and SSH. So I could redirect all those ports to different
ports on on faketarget (DNAT), then back to the real ports on realtarget
(using REDIRECT target?).

Can you give me an example (or point me to a URL) of what rules I would
need to run on realtarget to MARK the connections and then decide which
routing table to use?  Are we just talking about iptables commands, or is
there something additional that is required?
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Grant Taylor]

> Interesting. Are there any pre-packaged ways to do this? This sounds like
> perhaps the least complex solution, once it's actually implemented.

Pre-packaged solutions?  Um, sure, it's called Linux.  :P  No, I don't know of any ""pre-packaged solutions.  What there are is pre made building blocks that you can put together in to your own solution.

> That could work. I'm really only worried about DNS, HTTP, HTTPS, SMTP,
> POP3, IMAP, and SSH. So I could redirect all those ports to different
> ports on on faketarget (DNAT), then back to the real ports on realtarget
> (using REDIRECT target?).
> 
> Can you give me an example (or point me to a URL) of what rules I would
> need to run on realtarget to MARK the connections and then decide which
> routing table to use?  Are we just talking about iptables commands, or is
> there something additional that is required?

This is the command that you would need to run on the fake target to do the up and over part:

iptables -t nat -A PREROUTING -i $INet -d $FakeTargetIP -p tcp --dport 22 -j DNAT --to-destination $RealTargetIP:2222

This is the corresponding command that you would need to run on the real target to do the down and in part:

iptables -t mangle -A PREROUTING -i $INet -d $RealTargetIP -p tcp --dport 2222 -j MARK --set-mark $Mark
iptables -t nat -A PREROUTING -i $INet -d $RealTargetIP -p tcp --dport 2222 -j REDIRECT --to-ports 22

I'm not sure if you want the MARK target or the CONNMARK target as I have not worked with either of them.  But I think you see what I'm trying to accomplish with them.  As far as the rule, a little bit of reading should explain that (I'd have to do the reading my self at this hour).



Grant. . . .

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Grant Taylor wrote:
> This is the command that you would need to run on the fake target to do
> the up and over part:
> iptables -t nat -A PREROUTING -i $INet -d $FakeTargetIP -p tcp --dport
> 22 -j DNAT --to-destination $RealTargetIP:2222
> This is the corresponding command that you would need to run on the real
> target to do the down and in part:
> iptables -t mangle -A PREROUTING -i $INet -d $RealTargetIP -p tcp
> --dport 2222 -j MARK --set-mark $Mark
> iptables -t nat -A PREROUTING -i $INet -d $RealTargetIP -p tcp --dport
> 2222 -j REDIRECT --to-ports 22

Okay, I understand all this. Is this all that is necessary to make sure
the response packets go back through faketarget, though? Isn't this just
 taking care of the first part--the "up and over/down and in" part--but
not the second part, where packets need to go back to source through
faketarget?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Taylor, Grant]

> Okay, I understand all this. Is this all that is necessary to make sure
> the response packets go back through faketarget, though? Isn't this just
>  taking care of the first part--the "up and over/down and in" part--but
> not the second part, where packets need to go back to source through
> faketarget?

*nod*  I confess it was late and I was very tired when I wrote that email.  Yes you will need to do the corresponding in reverse, at least the up part and the unDNATing part should take care of the rest.  You will probably have to play with things a bit, but that should take care of you.



Grant. . . .

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Ray Van Dolson]

On Thu, Aug 11, 2005 at 09:07:00AM -0400, Adam Rosi-Kessel wrote:
> I'm relocating a web/email/ssh server from one location to another (and
> consequently to a new IP).  Since it's going to take many hours for the
> IP address changes to propagate across DNS, I'd like to put a proxy box

Not really related to achieving what you're asking, but if you have access to
the DNS records for the domains you're dealing with (and you have enough
leeway time), wouldn't it just be simpler to change your TTL to something like
60 seconds so the propagation time happens much more quickly?

I guess you have to chance things with misbehaving DNS servers that don't
honor TTL's and such ...

Ray

-- 
Ray Van Dolson
Linux/Unix Systems Administrator
Digital Path, Inc.

Re: Transparent proxy where source IP address remains unchanged -- possible?

[Adam Rosi-Kessel]

On Wed, Aug 17, 2005 at 02:07:15PM -0700, Ray Van Dolson wrote:
> On Thu, Aug 11, 2005 at 09:07:00AM -0400, Adam Rosi-Kessel wrote:
> > I'm relocating a web/email/ssh server from one location to another (and
> > consequently to a new IP).  Since it's going to take many hours for the
> > IP address changes to propagate across DNS, I'd like to put a proxy box
> Not really related to achieving what you're asking, but if you have access to
> the DNS records for the domains you're dealing with (and you have enough
> leeway time), wouldn't it just be simpler to change your TTL to something like
> 60 seconds so the propagation time happens much more quickly?

It's a good idea, but there's a whole bunch of domains, and I don't
control them all. I need to ask the domain owners to change the IP
addresses, and so the lag is not just the propagation time but also the
owner-change time--thus I want to forward packets for at least a while.
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org