iptables & routing problem

user · August 27, 2008, 2:08pm

Hello guys.
First at all, sorry, but my english is not good at all.

This is my situation.
I got an OpenSuSE 10.3 installed on a machine with 2 NICs, eth0 connected to internet and eth1 connected to lan.
eth1 is the default gateway of the lan (172.88.60.254/24).
The firewall´s rules was generated with FirewallBuilder 2.1.14.
I got an VPN´s endpoint Cisco3002 connected to the lan, with the private´s IP 172.88.60.1
So, I got on the linux box a route to redirect all the traffic for my headquarters, to the IP 172.88.60.1 and a firewall rule permit this traffic, on both ways.
IP forwarding is enabled.
This is my problem.
When I try to access to a pc on the lan 172.88.60.0/24 from headquarters, the firewall drops the packets.
If I try to access the OpenSuSE box using ssh from the headquarters, everything is all right
I try changing the forward policy to ACCEPT, but the problem remains

I put here my iptables:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RULE_0 0 – 200.61.185.97 0.0.0.0/0 state NEW
RULE_0 0 – 200.61.185.98 0.0.0.0/0 state NEW
RULE_0 0 – 200.61.185.99 0.0.0.0/0 state NEW
RULE_0 0 – 200.61.185.100 0.0.0.0/0 state NEW
RULE_0 0 – 172.88.60.254 0.0.0.0/0 state NEW
Cid4868F8035452.0 tcp – 0.0.0.0/0 200.61.185.97 tcp dpt:22 state NEW
RULE_2 0 – 172.88.60.0/24 0.0.0.0/0 state NEW
RULE_2 0 – 172.100.0.0/16 0.0.0.0/0 state NEW
RULE_3 0 – 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RULE_2 0 – 172.88.60.0/24 0.0.0.0/0 state NEW
RULE_2 0 – 172.100.0.0/16 0.0.0.0/0 state NEW
RULE_3 0 – 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
RULE_0 0 – 0.0.0.0/0 0.0.0.0/0 state NEW
RULE_2 0 – 172.88.60.0/24 0.0.0.0/0 state NEW
RULE_2 0 – 172.100.0.0/16 0.0.0.0/0 state NEW
RULE_3 0 – 0.0.0.0/0 0.0.0.0/0

Chain Cid4868F8035452.0 (1 references)
target prot opt source destination
RULE_1 0 – 200.123.136.5 0.0.0.0/0
RULE_1 0 – 201.216.225.169 0.0.0.0/0
RULE_1 0 – 200.45.135.178 0.0.0.0/0
RULE_1 0 – 200.45.135.179 0.0.0.0/0
RULE_1 0 – 200.45.135.180 0.0.0.0/0
RULE_1 0 – 200.45.135.181 0.0.0.0/0
RULE_1 0 – 200.45.135.182 0.0.0.0/0
RULE_1 0 – 200.45.135.183 0.0.0.0/0
RULE_1 0 – 200.45.135.184 0.0.0.0/0
RULE_1 0 – 200.45.135.185 0.0.0.0/0
RULE_1 0 – 200.45.135.187 0.0.0.0/0
RULE_1 0 – 200.45.135.188 0.0.0.0/0
RULE_1 0 – 200.45.135.190 0.0.0.0/0
RULE_1 0 – 172.17.1.254 0.0.0.0/0
RULE_1 0 – 172.100.100.253 0.0.0.0/0
RULE_1 0 – 201.234.26.114 0.0.0.0/0
RULE_1 0 – 201.234.26.115 0.0.0.0/0
RULE_1 0 – 201.234.26.116 0.0.0.0/0
RULE_1 0 – 201.234.26.117 0.0.0.0/0
RULE_1 0 – 201.234.26.118 0.0.0.0/0
RULE_1 0 – 201.234.26.119 0.0.0.0/0
RULE_1 0 – 201.234.26.120 0.0.0.0/0
RULE_1 0 – 201.234.26.121 0.0.0.0/0
RULE_1 0 – 201.234.26.123 0.0.0.0/0
RULE_1 0 – 201.234.26.124 0.0.0.0/0
RULE_1 0 – 201.234.26.125 0.0.0.0/0
RULE_1 0 – 201.234.26.126 0.0.0.0/0
RULE_1 0 – 172.17.2.254 0.0.0.0/0
RULE_1 0 – 172.100.101.254 0.0.0.0/0

Chain RULE_0 (6 references)
target prot opt source destination
LOG 0 – 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `RULE 0 – ACCEPT ’
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0

Chain RULE_1 (29 references)
target prot opt source destination
LOG 0 – 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `RULE 1 – ACCEPT ’
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0

Chain RULE_2 (6 references)
target prot opt source destination
LOG 0 – 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `RULE 2 – ACCEPT ’
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0

Chain RULE_3 (3 references)
target prot opt source destination
LOG 0 – 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `RULE 3 – DENY ’
DROP 0 – 0.0.0.0/0 0.0.0.0/0

Anybody can help me?

ken_yap · August 27, 2008, 2:58pm

Ok, it’s late and thinking about routing has made me sleepy, so I don’t claim this is correct, but I think if you read through this story below you will see what’s wrong with your routing setup.

Let’s give some names because I don’t want to keep typing IP addresses:

SUSE: your Linux gateway IP
Cisco: your Cisco VPN appliance IP
PC: one of your PC’s IP
HQ: an IP at headquarters

Let’s look at the life of a connection.

HQ sends a packet to PC. Arrives at Cisco. Cisco looks at the destination and says, ah, for a PC? I’ll just put this out on the LAN.
PC gets a packet with From: HQ, To: PC. No problems.
PC replies to packet. Sends out a packet with To: HQ, From: PC. Looks at routing rule and says, ah, need to send this to SUSE because it’s an external address.
SUSE gets packet. Is instructed to redirect it to Cisco. What is a redirect? It is a rewriting of the To: address (and maybe port, but we ignore port for now). So the packet gets rewritten as To: Cisco, From: PC.
Cisco gets the packet. To me huh? How nice of the PC. But I don’t have any process or application to accept it, so I’ll just drop it.

So you see the problem is that the redirect loses the original destination of the packet.

This is a common problem when the VPN device is not the gateway. I think you might want to look into masquerading on SUSE instead.

Anyway I’m falling asleep so this may be wrong but I hope this puts you on the right track.

user · August 27, 2008, 4:26pm

About point #1, the packets coming from HQ are dropped by the firewall, that is the problem.

This is an attemp of ssh from HQ to SUSE:

Aug 27 10:59:47 FW-EXT-SAR kernel: RULE 2 – ACCEPT IN=eth1 OUT= MAC=00:0e:0c:d0:2a:d2:00:0f:f8:44:bc:42:08:00 SRC=172.100.4.45 DST=172.88.60.254 LEN=52 TOS=0x00 PREC=0x00 TTL=62 ID=757 DF PROTO=TCP SPT=17830 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

This is an attemp from HQ to PC:

Aug 27 10:58:23 FW-EXT-SAR kernel: RULE 3 – DENY IN=eth1 OUT=eth1 SRC=172.88.60.3 DST=172.100.4.45 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=30161 PROTO=TCP SPT=3389 DPT=17826 WINDOW=16384 RES=0x00 ACK SYN URGP=0

user · August 27, 2008, 4:32pm

looking in depth, the firewall is dropping the returning traffic

why?

user · August 28, 2008, 3:20pm

about #5, the returning packet never arrive to CISCO, the packet is dropped at SUSE

so

any idea?

user · August 28, 2008, 5:16pm

I found this solution:

I change the rule that inspect the traffic between the LAN of the SUSE and HQ, I change the type from statefull to stateless.

Until now, all test are passed ok

I hope that this is the solucion.

What do you think about this solution?