Is there a way I can mangle the packets coming from a certain source address to a different source address and feed it to the local processes?

The scenario is as follows. I usually SSH into my home linux server from work and recently they installed an outbound load-balancer ( Radware Linkproof ) which switches routes ( 2 outgoing lines, one is a T1, the other is a DSL from a different provider ). This route-switching is not connection-based, but raw packet-based, which means at one moment I'm hitting my home server as 209.x.x.x and as 64.y.y.y the next. What I would like to do is to somehow achieve a SNAT effect the incoming 64.y.y.y packets to 209.x.x.x, ACCEPT them and 'cheat' my applications into dealing with a single IP, thereby help them preserve state.

Any quick pointers you could offer would be really appreciated.

well, to begin, your situation is very odd to me and i've never seen it before....the connection changin IP's DURING A SESSION just seems well....ignorant.

here is the iptables rule for SNAT on INPUT...i have NEVER tried this and i cant say it will work but.....here goes nuthin'.


iptables -A PREROUTING -t nat -s $INCOMMING -p tcp --dport $SSHPORT -j SNAT --to $NEWIP

now, that seems very shady to me but it what it says is:

if the source address is INCOMMING and the protocol/port is TCP/SSH then change the source port to NEWPORT. I put this in pre-routing so that it gets handled as soon as it hits the router box. the destination stuff is left unchanged so im assuming that if a packet comes in with the specified IP, it will be changed and then sent along for further process.

this was a shot in the dark. it looks like a combination of an SNAT type rule and a DNAT type rule (port forwarding and masquerading) tell me if that works out. i have to test that out myself one day when i have time.

Thanks for your reply, Robert.

The whole load-balancing thing was the 'next big thing' for our networking guys, but it hasn't worked out for us so far. Oh, well you know how it goes.

The SNAT target is valid only in the nat table and in the POSTROUTING chain. So iptables wouldn't eat it. I appreciate your help though.

whow, this can't be correct. Whether two consecutive packets follow different routes or not, they should orriginate from the same source ip? unless, of course there is nat on one of the routes along the way, which it should not.

ie, lets your machine at work's ip is 1.1.1.1 and your home machine is 2.2.2.2 then all network comming from your machine at work should be coming from 1.1.1.1 and that from your home from 2.2.2.2, irrespective of the actual route followed.

The only way this can be is if the load balancer actually performs nat on the packets passing through it, using different ip's for the two outbound devices.

Are your work using a private ip subnet for internal machines? which would explain a lot. Also, is the endpoints of the two outgoing pipes at the same location. If not, they will have to use connection based load balancing, not raw ip balancing.

Let me try to explain this better.

My work machine has an internet routable IP address ( say a.a.a.x) , but of course it is protected from 'the world' by a firewall. This address is routed through our main line ( T1 ) whose gateway is on the same subnet as my machine ( a.a.a.y ).

The other line is DSL from a different provider, and the gateway is b.b.b.z . Since b.b.b.z is different network altogether, if the load balancer decides to send out traffic via DSL ( send out requests from IP a.a.a.x through b.b.b.z) and if the packets were unaltered the returning packets will be routed through the T1 gateway [a.a.a.y ] which we do not want. What we want is that traffic sent out through either interface should recieve its response in through the same interface it was sent out through, so that if the other interface was down, our to and fro traffic wont be affected ( redundancy ). This means that for the DSL to receive the return traffic, the outgoing traffic has to be NATted to the DSL gateway address.

This means, I hit my home box as a.a.a.x as one moment and b.b.b.z the next, which is evident from my the output of the 'who' command. What I need to do is clear, but how to do it (without introducing *another* linux box in between my home machine and home router) is what I'm trying find out.

This is a *very* simplified network diagram with all unimportant elements ( firewalls, hubs, switches ) removed. This is my very first attempt using ASCII art ( yeah, this is artsy enough for me ) so forgive my inexperience.

//moderator.note: moved to appropriate forum: Linux - Networking

I don't think it can be done. The problem comes in at the point where it actually performs NAT on some of the packets but not on all. It's like receiving letters from different people, the only way you know who the letter comes from is by the name of the sender. Well, in the case of networks, the ip address serves as the name of the sender. But say you have more than one connection between two machines, then you need something else to distinguish between the packets, going back to the letter analogy, this can be seen as the topic of the letter (which can sometimes be ambigious), the source and destination ports is what clears this up in the case of computers (luckily this in unambigious).

So what they are in effect doing to the poor network by NAT'ing stuff on a per packet basis is screwing the poor receiver over, for example, say you are connecting from work, now the initial SYN packet goes via route 1, then the SYN/ACK packet will come back to that, now say the ACK packet goes back via route 1, then you will have a successfull connection established, if however that ACK packet follows route 2, your machine at home will see this as a violation of the IP standard and send an RST packet back via route 2 and the half-open connection that is stored in it's cache will eventually time whilst your machine at work will simply think that your machine at home have immediately closed the connection. This is basically what will happen if at any point one packet follows another route from the rest. They've got to come from the same IP, and it won't happen the way they are doing it. It just won't. Their going to have to do 1 of 2 things:

1) Do connection based load balancing.
2) Make sure that the ISP is not going to mind a bit of "spoofing" via that connection and send packets the way they are and receive all replies back via the T1 connection, or vice versa, receive everything back via the DSL (this way round sounds like it's going to be more trouble since you will have to sync the NAT tables on two machines in real time).

I would suggest trying option 1, how to actually do this I have no clue. Good luck.