Solved

Iptables static route setup

Posted on 2013-06-03
19
451 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
  • 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 39

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
 
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 39

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
How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

 
LVL 39

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 39

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 39

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 39

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

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Suggested Solutions

Article by: IanTh
Hi Guys After a whole weekend getting wake on lan over the internet working, I thought I would share the experience. Your firewall has to have a port forward for port 9 udp to your local broadcast x.x.x.255 but if that doesnt work, do it to a …
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.
Viewers will learn how to connect to a wireless network using the network security key. They will also learn how to access the IP address and DNS server for connections that must be done manually. After setting up a router, find the network security…
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

757 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now