I'm pretty sure that what I need done can be accomplished with iptables, but have been unable to find an example describing my situation.

Short version:  I want any packets coming from a particular netblock to appear to all systems behind the firewall as actually coming from a different netblock, for example, any traffic from 10.0.0.0/8 might appear to actually come from 192.0.0.0/8.

Long version:  I have multiple machines behind a NAT firewall.  One machine runs VPN software to connect to a corporate network, and occasionally I have a need to connect back to that machine from the office, and am unable to do so unless the VPN is turned off.  Since the traffic is coming in from an IP range that the machine running VPN has a separate route back to, it ends up routing the packets to the wrong interface, and the connection fails.  If I can make these packets appear to come from a different IP range, they should get routed out the correct interface.

Hopefully, that makes sense, and someone has a clue about what I need here.  I think that SNAT might be what I'm needing, but haven't found an example that seems similar to what I'm after.

your long version is quite confusing.

Is your "nat firewall" the device running openwrt? Is the same device also your internet router or is that function handled by a separate device?
Can we assume that the vpn box is used for remote access and not for site-to-site connectivity?
When you say that you "need to connect back to that machine from the office" is the office in a different place (and on a different layer-2 network) than the machines and nat firewall?

Could it be that the packets are finding their way to your vpn box fine but on their way out they follow the vpn route rather than the machine's default gateway? If so, that is not an openwrt problem.

Also, I would recommend against using 192.0.0.0/8 anywhere on your lan as you will probably loose access to lots of public ip addresses. (private non-routeable address range is 192.168.0.0/16)

Kyri, I have OpenWrt set up as router and NAT firewall via a cablemodem connection to the internet.  All machines on my local network (192.x.x.x) are behind this firewall, this network is at my home.

On my home desktop system I'm running an application providing a software VPN connection to my corporate network (different layer 2, different physical location, etc), example range above was 10.0.0.0/8, but that is not actually the real network range, just a generic example.  This same desktop is also used for surfing the web, email, etc, so I need to be sure that no other connectivity is effected.

From my office (10.x network), I need to connect to my home desktop.  I use a dynamic DNS address, and use port mapping via OpenWrt to handle the connections properly.  So, from a variety of different IP addresses at the office, I may need to connect back to the home system with something like:  example.com:1234

I believe that you are correct that the packets come in correctly, but are attempting to leave via the VPN route, since that machine will think that this is the correct path, and consequently the reply packets will look like they came from the assigned VPN address and end up being discarded by the machine that is trying to establish the connection.  I understand that this isn't an OpenWrt problem, but I'm hoping that OpenWrt may in fact be a solution. 

My original thought was to somehow alter the packets so that anything originating from 10.x would get altered, so that the VPN wouldn't send replies using the 'wrong' address, but in thinking about this now that might work, but would impact any legitimate outgoing traffic from this same machine to the corporate network outside of VPN, public servers, etc, reply packets for those connections would get altered and get discarded by my desktop...  Hmmm...

Thought of something that might help...  I don't need to worry about handling traffic on all ports, only a small number of ports for services on the desktop machine, file sharing, screen sharing, etc.  I already have existing rules for port forwarding that work correctly going to that machine, perhaps I could add something to those rules so that only traffic on those particular ports has the source IP altered?

Here's an example of one of my rules:

iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 5555 -j DNAT --to $server2:548
iptables        -A forwarding_rule -d $server2 -p tcp --dport 548 -j ACCEPT
# iptables -t nat -A postrouting_rule -o $LAN -p tcp -s $network -d $server2 -m multiport --dports 548 -j SNAT --to-source $WANIP

(Last edited by JimWright on 3 Sep 2009, 23:47)

Well, I darned near had it there, that last line was the trick, here's the working version:

# AFP
iptables -t nat -A prerouting_rule -d $WANIP -p tcp --dport 5555 -j DNAT --to $server2:548
iptables        -A forwarding_rule -d $server2 -p tcp --dport 548 -j ACCEPT
iptables -t nat -A postrouting_rule -o $LAN -p tcp -d $server2 --dport 548 -j SNAT --to-source $WANIP

This was a line that I had recycled from some other code without fully checking all the parameters.  Dropping a few parameters that weren't needed did the trick, and only traffic on this particular port for this particular server is touched.

I've tested this now with and without VPN running on that machine (server2), and it's working just fine.  Hope this helps someone!

Hello Jim, since I disagree with your proposed workaround of modifying packets in this way I will attempt to find a better solution for you.

First my assumptions:

1)You have some services running on your home machine, made accessible over the internet via dynamic dns and port forwarding (in the form of jim.dynamicdnshost.org:portno)

2)You can access these services fine from anywhere in the world (including your office network which is also connected to the internet).

3)Your company provides remote access vpn connectivity, and you have this functionality on your home pc.

4)When the vpn tunnel is up you can no longer access these services from your office pc, or any other pc in the corporate network.

5) If you try to access these services (with your vpn tunnel up) from somewhere else on the internet all is ok. The problem only occurs when you're trying to gain access from behind your corporate network.

6) When the tunnel is up you can access the services that exist on the home pc by using the ip address your home pc has on the corporate network. (e.g. 10.0.0.55:8080). You might even be able to use the dns name of your home pc on the corporate network e.g. jimshomepc.corporatelan.local:8080 (especially if your company runs Active Directory and the vpn solution is AD-integrated e.g. ISA Server)

Let me know if what I've stated above is correct before I attempt to tackle the problem.

Kyri

(Last edited by kyri on 3 Sep 2009, 23:59)

kyri, you're spot on with all assumptions.  Regarding point 6, I did verify that using the assigned VPN IP to connect did indeed work, but as this would change with each connection, didn't seem like the ideal way to handle this.  I did think of writing a script that would watch for VPN connections to be active, check the IP address, and update a dynamic DNS address specifically for that purpose, but this would have ended up with me having two separate DNS names for the same machine, depending on whether VPN was running or not, and VPN does drop unexpectedly on occasion, so there would be times where I'd end up having to try both addresses...

If you can think of an alternate workaround, I'm all ears, but what exactly is your concern with the particular solution I've set up?

There's a utility for Linux called "redir" that might suit your needs. I'd used it in the past to make certain external IP connections pretend to be internal LAN connections, "tricking" my firewall so to speak.