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 There is a response from 10.49.41.127, Tom. Please take a look at the following output:
# ping is being initiated from 192.168.1.2/32 host root@client:~# ping 10.49.41.127 PING 10.49.41.127 (10.49.41.127) 56(84) bytes of data. [and it's sitting like that all the time] # capturing data on server side on both eth0 and eth1 interfaces root@devel:~# tcpdump -n -i eth1 icmp 01:12:18.940568 IP 192.168.1.2 > 10.49.41.127: ICMP echo request, id 1369, seq 1958, length 64 01:12:19.948138 IP 192.168.1.2 > 10.49.41.127: ICMP echo request, id 1369, seq 1959, length 64 ^C and the same thing done for eth0 shows icmp echo reply whch are returning from 10.49.41.127 to 10.44.70.195: root@devel:~# tcpdump -n -i eth0 icmp 01:12:08.926992 IP 10.49.41.127 > 10.44.70.195: ICMP echo reply, id 1369, seq 1948, length 64 01:12:09.936291 IP 10.49.41.127 > 10.44.70.195: ICMP echo reply, id 1369, seq 1949, length 64 ^C and now I can't figure out why these packets are not passing ethX to reach 192.168.1.2/32 host. ------------------------------------------------------------------------------ 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
