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.


Best regards,
Kris

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

Reply via email to