On 10/18/12 3:49 PM, "Krzysiek Nowak" <[email protected]> wrote:
>On 10/18/2012 08:19 AM, Krzysiek Nowak wrote: >>> On 10/18/2012 07:54 AM, Krzysiek Nowak wrote: >>>>>>> Hello! >>>>>>> >>>>>>> >>>>>>> I'd like to ask if it is possible to connect local LAN network with >>>>>>> external one to which access is provided by tap0 adapter (ShrewSoft >>>>>>> connecting to CheckpointVPN gateway)? I have a server with eth0 >>>>>>>adapter >>>>>>> which is used as WAN adapter, tap0 (VPN) and eth1 which is acting >>>>>>>as LAN >>>>>>> interface. What I want to do is to grant access for users from >>>>>>>this LAN >>>>>>> (eth1) to network 10.49.41.0/24 available when tun0 is connected >>>>>>>to VPN. >>>>>>> Is it possible with Shorewall? If so, how? >>>>>>> >>>>>>> internet >>>>>>> | >>>>>>> |-eth0:10.48.10.27/24--->-| >>>>>>> ^ tap0:10.44.70.68/32 [shrew soft connecting to CheckPoint >>>>>>>VPN, DHCP] >>>>>>> | >>>>>>> |-eth1:192.168.1.1/24---<-| >>>>>>> ^ >>>>>>> | >>>>>>> <-LAN >>>>>>> ^ >>>>>>> | >>>>>>> < - 192.168.1.2/24 [how to >>>>>>>connect to >>>>>>> 10.49.41.111/32 ?] >>>>>> Kris, >>>>>> >>>>>> There are two parts to this problem: >>>>>> >>>>>> a) Allowing the traffic. >>>>>> b) Routing. >>>>>> >>>>>> The first part is easy. Define a zone 'vpn' to be associated with >>>>>>tap0, >>>>>> then configure policies/rules to permit the traffic you want to >>>>>>allow. >>>>>> >>>>>> The second part will require that you masquerade traffic from your >>>>>>local >>>>>> LAN to the remote network, unless the remote end can be configured >>>>>>to >>>>>> route 192.168.1.1/24 through the VPN. If that isn't possible, then >>>>>>you >>>>>> need this in the masq file: >>>>>> >>>>>> tap0 192.168.1.0/24 >>>>>> >>>>>> -Tom >>>>> Hi Tom, >>>>> >>>>> >>>>> Thank you for your answer. I did that and it's still not working. >>>>> >>>>> Oct 18 16:50:31 devel kernel: [89702.530584] >>>>> Shorewall:loc2vpn:ACCEPT:IN=eth1 OUT=tap0 >>>>> MAC=00:21:91:f4:6c:44:5c:26:0a:05:fc:51:08:00 SRC=192.168.1.2 >>>>> DST=10.49.41.127 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=701 DF >>>>>PROTO=TCP >>>>> SPT=12635 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 >>>>> Oct 18 16:50:53 devel kernel: [89725.034448] >>>>> Shorewall:loc2vpn:ACCEPT:IN=eth1 OUT=tap0 >>>>> MAC=00:21:91:f4:6c:44:5c:26:0a:05:fc:51:08:00 SRC=192.168.1.2 >>>>> DST=10.49.41.131 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=1655 DF >>>>>PROTO=TCP >>>>> SPT=12636 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 >>>>> Oct 18 16:51:16 devel kernel: [89747.989691] >>>>> Shorewall:loc2vpn:ACCEPT:IN=eth1 OUT=tap0 >>>>> MAC=00:21:91:f4:6c:44:5c:26:0a:05:fc:51:08:00 SRC=192.168.1.2 >>>>> DST=10.49.41.111 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=1682 DF >>>>>PROTO=TCP >>>>> SPT=12639 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 >>>>> ^C >>>> What do you see when you run tcpdump on tap0? >>>> >>>> tcpdump -nei tap0 >>>> >>>> -Tom >>> [root@devel ~] # tcpdump -vvv -nei tap0 >>> tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size >>> 65535 bytes >>> ^C >>> 0 packets captured >>> 0 packets received by filter >>> 0 packets dropped by kernel >>> >>> This is strange. After issuing this command I tried to connect to >>>remote >>> host (10.49.41.x) from 192.168.1.0/24 network and from server itself. >>> Now, funny thing is that when I configure another tunnel on tun0 >>> interface (tun0, not tap0) and connecting to other VPN gateway (cisco >>> appliance) from 192.168.1.0/24 network all is working fine! That is >>> pointing to what actually? ShrewSoft's VPN configuration on server >>> (192.168.1.1) ? I saw there some 'nat' related options and I think I >>> need to read about them. I hope it's not an issue with tap/tun >>> interfaces. Or maybe you have other suggestions Tom? >> Sorry -- I know nothing about ShrewSoft. >> >> -Tom >Sure Tom, no problem. I understand that. > >This tap0 interface got me thinking and apparently some other people had >the same problem (with packets not showing on that interface). I guess >it has nothing to do with shorewall itself, but for sure it's related to >VPN, iptables and kernel and therefore I am pasting some resources here: > >http://lists.shrew.net/pipermail/vpn-help/2011-April/003658.html >http://unix.stackexchange.com/questions/24215/why-are-incoming-packets-on- >a-tap-interface-seen-with-tcpdump-but-not-with-iptab > >Now, when I do this: > >root@devel:~# tcpdump -nai eth0 -vvv host 10.49.41.127 > >and start ping to 10.49.41.127/32 from 192.168.1.0/24 I can see: > >00:39:51.496657 IP (tos 0x0, ttl 62, id 64351, offset 0, flags [none], >proto ICMP (1), length 84) > 10.49.41.127 > 10.44.70.195: ICMP echo reply, id 1369, seq 24, length >64 >00:39:52.506540 IP (tos 0x0, ttl 62, id 64352, offset 0, flags [none], >proto ICMP (1), length 84) > 10.49.41.127 > 10.44.70.195: ICMP echo reply, id 1369, seq 25, length >64 > >So after all there seems to be response from remote host, but why ICMP >reply packet is not reaching 192.168.1.0/24? The 10.44.70.195 address is >the one assigned to tap0 interface after successful VPN initiaion. But that isn't the address you should be seeing in the response at eth0; you should be seeing 10.49.41.127. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
