Solved

Iptables static route setup

Posted on 2013-06-03
19
468 Views
Last Modified: 2013-06-17
I have a Debian Linux based router that is working good. We now have to add a second router for a VPN connection back to a vendor. The eth1 interface of the Debian router is at 192.168.1.254. The LAN interface for the new router is set to 192.168.1.253. I added a static route for the network on the Debian router and I can ping hosts on the VPN connected network. I cannot ping any host on the VPN connected network from any LAN computers (all of which have 192.168.1.254 as the default gateway). I tried adding a DNAT rule to the POSTROUTING chain but that didn't seem to help. I am guessing I am missing something glaring here but am tired of beating my head against the keyboard. I can post examples if that would help. I just typed this quick while drinking a um coffee, yea that's it.
0
Comment
Question by:bdhtechnology
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 6
  • 5
  • +2
19 Comments
 
LVL 1

Author Comment

by:bdhtechnology
ID: 39219244
Here are the relevant lines from my firewall script:
echo 1 > /proc/sys/net/ipv4/ip_forward

/sbin/iptables -t nat -A PREROUTING -j DNAT -s 0.0.0.0/0 -d 172.20.145.0/24 --to-destination 192.168.1.253
/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE -s 0.0.0.0/0 -d 0.0.0.0/0 -o eth0

Open in new window


Here is the routing table from the Debian router
netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         xxx.xxx.94.86   0.0.0.0         UG        0 0          0 eth0
10.144.105.0    192.168.1.251   255.255.255.0   UG        0 0          0 eth1
172.20.145.0    192.168.1.253   255.255.255.0   UG        0 0          0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
xxx.xxx.94.80   0.0.0.0         255.255.255.248 U         0 0          0 eth0

Open in new window


But when I ping the host that I need to reach: 172.20.145.67  I get no response from any computers on the LAN.
0
 
LVL 16

Expert Comment

by:gurutc
ID: 39220008
hmmm, looking.

- gurutc
0
 
LVL 40

Expert Comment

by:noci
ID: 39220036
why the DNAT?
If you want to route to 172.20.145.0/24 you need to add a route:

route add -net 172.20.145.0/24 gw ip.of.vpn.device

that should suffice.
0
Secure Your WordPress Site: 5 Essential Approaches

WordPress is the web's most popular CMS, but its dominance also makes it a target for attackers. Our eBook will show you how to:

Prevent costly exploits of core and plugin vulnerabilities
Repel automated attacks
Lock down your dashboard, secure your code, and protect your users

 
LVL 1

Author Comment

by:bdhtechnology
ID: 39220057
That is what I thought, the route works fine on the router, but the LAN computer do not reply.  Is the problem that they don't have proper routes setup in the vendor's router?
0
 
LVL 20

Expert Comment

by:Daniel McAllister
ID: 39220468
If you can ping systems on the other end of the VPN, but they cannot ping you back, then the routing issue is on their end.

Dan
IT4SOHO
0
 
LVL 40

Expert Comment

by:noci
ID: 39220480
what routes did they setup, if you only got one from your router then yes that might be a problem.
In that case you only need source NAT on all packets going to the device, nothing else, that will point all records back to your router, which will un nat them.

Other systems are not reachable directly though.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 39220571
Personally I don't use the MASQUERADE target, I find SNAT in POSTROUTING to be adequate.
Could you please post the output from
set -x;for i in filter nat mangle raw;do iptables -t $i -n -v --line-numbers -L;done;set +x

Open in new window

xxx out any fields you feel you have to (I hate that) but take especial care to do it consistently.
Sorry I have to go now - will look in again later.
0
 
LVL 1

Author Comment

by:bdhtechnology
ID: 39221827
@noci
I don't believe they set any routes up at all.  Unless I am thinking about this incorrectly I don't know that they would need to.  The vendor's router has a LAN facing interface at 192.168.1.253 and therefore should be able to talk to everything on the 192.168.1.0/24 subnet.  Since I can't see their router I am not sure what is happening, but would it be possible that since my Debian router is supposed to be forwarding the traffic that they would be sending the traffic back to the Debian router at 192.168.1.254?  I added additional logging on all the tables but I don't see anything coming back like that at all.

@duncan_roe
I have not used SNAT before, it's always been MASQUERADE, but it looks like SNAT works well as long as the IP is static, which it is.  I will look into changing that.

I only masked the first 2 octets of the public IP address on the output below, as well as the rest of the examples.  I did it with a simple find and replace so it is definitely consistent
set -x;for i in filter nat mangle raw;do iptables -t $i -n -v --line-numbers -L;done;set +x
+ for i in filter nat mangle raw
+ iptables -t filter -n -v --line-numbers -L
Chain INPUT (policy DROP 921 packets, 52352 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        all  --  *      *       172.20.145.0/24      0.0.0.0/0            LOG flags 0 level 4 prefix " ##B_S INPUT S LOG## "
2        0     0 LOG        all  --  *      *       0.0.0.0/0            172.20.145.0/24      LOG flags 0 level 4 prefix " ##B_S INPUT D LOG## "
3     5089  756K ACCEPT     all  --  *      *       192.168.1.0/24       0.0.0.0/0           
4        0     0 ACCEPT     all  --  *      *       xxx.xxx.94.81        0.0.0.0/0           
5     3122  634K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
6        0     0 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
7    11992 1877K ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
8        0     0 ACCEPT     all  --  eth1   *       192.168.1.0/24       192.168.1.0/24      
9        0     0 ACCEPT     all  --  eth1   *       192.168.1.0/24       xxx.xxx.94.80/29    
10       7   294 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
11       0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0           
12       2    92 ACCEPT     tcp  --  *      *       0.0.0.0/0            xxx.xxx.94.81        tcp spts:1024:65535 dpt:2222
13      42  2212 ACCEPT     tcp  --  *      *       0.0.0.0/0            xxx.xxx.94.81        tcp spts:1024:65535 dpt:5900
14       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67
15       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
16       4   208 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpts:135:139
17       3   234 DROP       udp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     udp dpts:135:139
18       3   152 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:445
19       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpts:1024:1035
20       0     0 DROP       udp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     udp dpts:1024:1035
21      11   440 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:1433
22       0     0 DROP       udp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     udp dpt:1434
23       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:2745
24       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:3127
25       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:3631
26       0     0 DROP       udp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     udp dpt:3631
27       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:3738
28       0     0 DROP       udp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     udp dpt:3738
29       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:3739
30       0     0 DROP       udp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     udp dpt:3739
31       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:5000
32       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:6129
33       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:15118
34       0     0 DROP       tcp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     tcp dpt:31572
35       0     0 DROP       udp  --  *      *      !192.168.1.0/24       xxx.xxx.94.80/29     udp dpt:31572
36     921 52352 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix " ##INPUT DENY LOG## "

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        all  --  *      *       172.20.145.0/24      0.0.0.0/0            LOG flags 0 level 4 prefix " ##B_S FORWARD S LOG## "
2        0     0 LOG        all  --  *      *       0.0.0.0/0            172.20.145.0/24      LOG flags 0 level 4 prefix " ##B_S FORWARD D LOG## "
3        0     0 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
4        0     0 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0           
5        0     0 ACCEPT     all  --  ppp+   *       0.0.0.0/0            0.0.0.0/0           
6        0     0 ACCEPT     all  --  *      ppp+    0.0.0.0/0            0.0.0.0/0           
7        0     0 ACCEPT     all  --  *      *       192.168.1.0/24       172.20.145.0/24     
8        0     0 ACCEPT     all  --  *      *       172.20.145.0/24      192.168.1.0/24      
9      710 28562 ACCEPT     all  --  *      *       192.168.1.0/24       10.144.105.0/24     
10       0     0 ACCEPT     all  --  *      *       10.144.105.0/24      192.168.1.0/24      
11    662K  666M ACCEPT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
12    1675  103K ACCEPT     all  --  *      *       0.0.0.0/0            192.168.1.0/24      
13    511K   79M ACCEPT     all  --  *      *       192.168.1.0/24       0.0.0.0/0           
14       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix " ##FORWARD DENY LOG## "

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        all  --  *      *       172.20.145.0/24      0.0.0.0/0            LOG flags 0 level 4 prefix " ##B_S OUTPUT S LOG## "
2        0     0 LOG        all  --  *      *       0.0.0.0/0            172.20.145.0/24      LOG flags 0 level 4 prefix " ##B_S OUTPUT D LOG## "
3      106 10038 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.1.0/24      
4     3122  634K ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
5        0     0 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0           
6        0     0 ACCEPT     all  --  *      ppp+    0.0.0.0/0            0.0.0.0/0           
7     8363   13M ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
8        0     0 ACCEPT     all  --  *      *       xxx.xxx.94.80/29     xxx.xxx.94.80/29    
9        0     0 ACCEPT     all  --  *      *       192.168.1.0/24       0.0.0.0/0           
10       0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
11    2797  173K ACCEPT     all  --  *      *       xxx.xxx.94.81        0.0.0.0/0           
12       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix " ##OUTPUT ACCEPT LOG## "
+ for i in filter nat mangle raw
+ iptables -t nat -n -v --line-numbers -L
Chain PREROUTING (policy ACCEPT 67679 packets, 14M bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        all  --  *      *       172.20.145.0/24      0.0.0.0/0            LOG flags 0 level 4 prefix " ##B_S PREROUTING S LOG## "
2        6   524 LOG        all  --  *      *       0.0.0.0/0            172.20.145.0/24      LOG flags 0 level 4 prefix " ##B_S PREROUTING D LOG## "
3        6   524 DNAT       all  --  *      *       0.0.0.0/0            172.20.145.0/24      to:192.168.1.253
4        1   249 DNAT       all  --  *      *       0.0.0.0/0            10.144.105.0/24      to:192.168.1.251

Chain INPUT (policy ACCEPT 2932 packets, 551K bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2755 packets, 166K bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 227 packets, 9417 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        all  --  *      *       172.20.145.0/24      0.0.0.0/0            LOG flags 0 level 4 prefix "  ##B_S POSTROUTING S LOG## "
2        0     0 LOG        all  --  *      *       0.0.0.0/0            172.20.145.0/24      LOG flags 0 level 4 prefix "  ##B_S POSTROUTING D LOG## "
3    35135 1966K MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           
+ for i in filter nat mangle raw
+ iptables -t mangle -n -v --line-numbers -L
Chain PREROUTING (policy ACCEPT 107 packets, 10913 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 67 packets, 5853 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 30 packets, 1754 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 63 packets, 73589 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 93 packets, 75343 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
+ for i in filter nat mangle raw
+ iptables -t raw -n -v --line-numbers -L
Chain PREROUTING (policy ACCEPT 107 packets, 10913 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 61 packets, 72605 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
+ set +x

Open in new window

0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 39222005
Now it's too late for me to really get my head around this thoroughly. And I've got to leave early tomorrow for the Dentist.
But I drew a little diagram of your setup, and I think I may have a clue.
Both routers are on the same LAN, and all other systems nominate the Debian one (host 254).
The Debian router knows to route internally generated segments for VPN 172.20.145.0/24 to the other router (host number 253). So you can ping fine from there. But if other systems route packets to the Debian router which are destined for the VPN, there is nothing you can do. If you push the segment back out through eth1 it is just going to come back because its routing info says to go to host 254. There is no iptables command to change that (that I can find).
What you need to do is update the routing tables on all 192.168.1.0/24 hosts to route packets for the VPN 172.20.145.0/24 to go via 192.168.1.253
0
 
LVL 40

Accepted Solution

by:
noci earned 300 total points
ID: 39222884
First of all, to make it clear this is a routing problem, not a filter problem.
So it should be solved by adding the RIGHT route on all systems that need it. (prefered)
OR a router should be put between in.

Either by using an extra interface and connect then VPN device to it.
or by making it look like all packets came from the firewall/gateway device anyway.

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 172.20.145.0/24 -j SNAT --to-source 192.168.1.254
route add -net 172.20.145.0/24 gw 192.168.1.253

The route will forward the packets, the SNAT will make sure things come back.
Now not all kernels are very happy with natting U-turn packets (Leaving the same interface they came in on) i have no list of kernels that do support it or dont. [ depending on kernel version ]. so YMMV.

Also this doesn't make it possible for 172.20.145.0/20 devices to connect to you.
If you want to filter traffic in between make sure you get a proper setup with the VPN device on a separate interface on the linux system... You may need to change addresses
on the LAN interface....

Another option may be to just run the VPN software on you linux system.
It can do IPSEC VPN's (prefered over) & SSL VPN's. So you may not need a whole new box anyway.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 39223998
If you want The route will forward the packets to actually happen then you need to add the rule to FORWARD table, not POSTROUTING. By definition, route is not going to do anything further to packets that get to POSTROUTING.
How reply packets can ever then get back to the originating node beats me. Try it if you like by all means, but I still think you have to fix routing on the originating systems.
0
 
LVL 40

Expert Comment

by:noci
ID: 39224228
For ROUTING to happen a forward may be needed, depending on default of FORWARD,
but there those needed were mentioned.

To ensure packets return throuhg this system (might be needed as not all systems work fine with triangular routing)  one can also source NAT the packets to force them back over this system.

Actualy there is another method that can be used. ICMP-redirect but that's something you don't want to use as it will open a can of worms w.r.t. security & reliability on a network.
But for the sake of completeness i'll mention it.
0
 
LVL 1

Author Comment

by:bdhtechnology
ID: 39225300
That didn't seem to work.  Maybe this won't work without adding a route on each device for the VPN 172.20.145.0/24 to go via 192.168.1.253  which does work.  I can add a persistent route on each PC but for things like printers that isn't as easy to do.  Though most of the printers don't need Internet access so we can set their default gateway to .253

I wish we had control of the vendor's VPN router, but this is for a connection to a banking service center and as such they aren't willing to let us setup our own VPN tunnels.  Lots of red tape there.

Thanks for the help but I guess this isn't possible like I had thought.  It just seems like something that *should* work.
0
 
LVL 34

Assisted Solution

by:Duncan Roe
Duncan Roe earned 200 total points
ID: 39227279
Must disagree there - having 2 routers attached to the same network is just not mainstream.
Here's what I would do: slip an extra NIC card into your Debian router. Make its address anything you like: 10.0.0.1, 192.168.42.1 ... anything at all. Specify that the vendors VPN router is to be attached to that network.
Inside your Debian router, route 172.20.145.0/24 to the new NIC in the normal way.
0
 
LVL 40

Expert Comment

by:noci
ID: 39227608
I agree duncan, problem is that the LAN interface of the router needs to be modified TOO to make this work. The Asker stated that it's from a banking firm that doesn't chancge that.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 39228570
The bank won't let him play with the insides of it, but its local interface address has to be whatever he tells them. We'll hear soon enough
0
 
LVL 40

Expert Comment

by:noci
ID: 39229557
If the local interface gets f.e. 10.0.1.0/24
The tunnel specification still needs to allow 192.168.1.0/24 and NOT 10.0.1.0/24 otherwise the problems of end to end communication are still not solved...
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 39230811
Yes they are. We're doing regular NAT in the Debian router.
It is in any case possible to have 2 NIC cards with the same Ethernet address - I did that once years ago. You just have to take a little care with routing. But I don't think that will be necessary.
0
 
LVL 1

Author Closing Comment

by:bdhtechnology
ID: 39252784
Thank you for your assistance on this.  What you had both said made a lot of sense.  I think adding another NIC would have worked for this, however the problem is they have 3 of these routers connected to 3 different providers.  It is definitely not mainstream and I have never seen this before.  We have added persistent routes to all the computers but we actually have to modify the default gateway of the printers for them to work properly.  It is kind of a pain, but it is even more painful to have them reconfigure their routers to a different internal network, since they will not give us access at all to them.
0

Featured Post

SharePoint Admin?

Enable Your Employees To Focus On The Core With Intuitive Onscreen Guidance That is With You At The Moment of Need.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Don’t let your business fall victim to the coming apocalypse – use our Survival Guide for the Fax Apocalypse to identify the risks and signs of zombie fax activities at your business.
If you're not part of the solution, you're part of the problem.   Tips on how to secure IoT devices, even the dumbest ones, so they can't be used as part of a DDoS botnet.  Use PRTG Network Monitor as one of the building blocks, to detect unusual…
Internet Business Fax to Email Made Easy - With  eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, f…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

738 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question