[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

[Openvpn-users] RE: Re: Re: Re: Re: Routing forever


  • Subject: [Openvpn-users] RE: Re: Re: Re: Re: Routing forever
  • From: Jochen Witte <jwitte@xxxxxxxxxxxxx>
  • Date: Fri, 21 Jan 2005 14:38:10 +0100

Am Fri, 21 Jan 2005 08:13:20 -0500 schrieb Tibbs, Richard:

> How were you using ipsec?
> Between GW1 and GW2 or host-to-host?
GW1 <-> GW2

> How did you flush ipsec (what command)?
>
setkey. (flush and spdflush) 
Try 
	man setkey

> Thanks.
> Rick.
> 
> -----Original Message-----
> From: openvpn-users-admin@xxxxxxxxxxxxxxxxxxxxx
> [mailto:openvpn-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jochen
> Witte
> Sent: Friday, January 21, 2005 3:47 AM
> To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> Subject: [Openvpn-users] Re: Re: Re: Re: Routing forever
> 
> Am Thu, 20 Jan 2005 18:01:51 +0100 schrieb Jochen Witte:
> 
>> Am Thu, 20 Jan 2005 17:02:38 +0100 schrieb Mathias Sundman:
>> 
>>> On Thu, 20 Jan 2005, Jochen Witte wrote:
>>> 
>>>> Am Thu, 20 Jan 2005 15:17:22 +0100 schrieb Mathias Sundman:
>>>>
>>>>> On Thu, 20 Jan 2005, Jochen Witte wrote:
>>>>>
>>>>>>>>>> I have a rather simple setup:
>>>>>>>>>> - 2 static, public ip servers (<pip1>, <pip2>)
>>>>>>>>>> - 2 private subnets (10.128.0.0/24, 192.168.0.0/24)
>>>>>>>>>> - OpenVPN network: 10.129.0.1<->10.129.0.2
>>>>>>>>>>
>>>>>>>>>> Here is the picture:
>>>>>>>>>>
>>>>>>>>>> Subnet A                 GW1            GW2           SubnetB
>>>>>>>>>> 10.128.0.0/24<--->10.128.0.1
> 192.168.0.254<--->192.168.0.0/24
>>>>>>>>>>                       |                 |
>>>>>>>>>>                  10.129.0.1        10.129.0.2
>>>>>>>>>>                   (<pip1>)<-------->(<pip2>)
>>>>>>>>>>                              VPN
>>>>>>>>>>
>>>>>>>>>> Obviously this is a routing problem (no firewalling, since all
> packets are
>>>>>>>>>> logged for debuggung).
>>>>>>>>>>
>>>>>>>>>> GW1 routes:
>>>>>>>>>> 10.129.0.2  0.0.0.0         255.255.255.255 UH    0      0
> 0 tun0
>>>>>>>>>> <pipnet1>   0.0.0.0         255.255.255.248 U     0      0
> 0 eth1
>>>>>>>>>> 10.128.0.0  0.0.0.0         255.255.255.0   U     0      0
> 0 eth0
>>>>>>>>>> 192.168.0.0 10.129.0.2      255.255.255.0   UG    0      0
> 0 tun0
>>>>>>>>>> 169.254.0.0 0.0.0.0         255.255.0.0     U     0      0
> 0 eth1
>>>>>>>>>> 0.0.0.0     <default-gw>    0.0.0.0         UG    0      0
> 0 eth1
>>>>>>>>>>
>>>>>>>>>> GW2 routes:
>>>>>>>>>> <default-gw>    0.0.0.0    255.255.255.255 UH    0      0
> 0 ppp0
>>>>>>>>>> 10.129.0.1      0.0.0.0    255.255.255.255 UH    0      0
> 0 tun0
>>>>>>>>>> 10.128.0.0      10.129.0.1 255.255.255.0   UG    0      0
> 0 tun0
>>>>>>>>>> 192.168.0.0     0.0.0.0    255.255.0.0     U     0      0
> 0 eth0
>>>>>>>>>> 0.0.0.0         <default-gw>  0.0.0.0      UG    0      0
> 0 ppp0
>>>>>>>>
>>>>>>>> The packets get stuck immediately in the gateway. (GW1 for
> packets from
>>>>>>>> 10.128.0.0 and GW2 for 192.168.0.0).
>>>>>>>
>>>>>>> Can you see it both on the ethX device and on tun0?
>>>>>>>
>>>>>> No, I just see it on my internal ethx and then it is gone. I even
> can't
>>>>>> see it on the external device (e.g. ppp0)
>>>>>
>>>>> Then I'd bet on a firewall problem after all. If routing is
> enabled, but
>>>>> you still can't see the packet traverse from ethX to tun0, then
> it's most
>>>>> likly blocked by netfilter.
>>>>>
>>>>> If you would have seen it on some other interface, like ppp0, then
> it
>>>>> would have been a routing problem.
>>>>
>>>> Hm, I do not agree. I log all traffic to example host 10.128.0.10
> with:
>>>>
>>>>        # Log-Chain
>>>>        ###########
>>>>        $IPTABLES -N my_log
>>>>        $IPTABLES -A my_log -p ICMP -j LOG --log-level info
> --log-prefix "LOG-ICMP "
>>>>        $IPTABLES -A my_log -p UDP -j LOG --log-level info
> --log-prefix "LOG-UDP "
>>>>        $IPTABLES -A my_log -p TCP -j LOG --log-level info
> --log-prefix "LOG-TCP "
>>>>
>>>> $IPTABLES -A FORWARD -d 10.128.0.10 -j my_log
>>>> $IPTABLES -A INPUT -d 10.128.0.10 -j my_log
>>>> $IPTABLES -A OUTPUT -d 10.128.0.10 -j my_log
>>>>
>>>>
>>>> This is one of the first things I do in my script.
>>>> I can see packages, when sending from the GW:
>>>>
>>>> Jan 20 15:55:48 <host> kernel: LOG-ICMP IN= OUT=tun0 SRC=10.129.0.2
>>>> DST=10.128.0.10 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP
> TYPE=8
>>>> CODE=0 ID=51242 SEQ=0
>>>>
>>>> But nothing happens, when sending from the inside host.
>>> 
>>> Hm, so the packet arrives on eth0, it's not routed to any other
> interface, 
>>> and not seen by netfilter via your log rules.
>>> 
>>> Stills smells like a simple typo in the firewall ruleset to me.
>>> 
>>> Some things to check:
>>> 
>>> Is rp_filter enabled? Could it be causing any problems. I really
> don't 
>>> know, as I've never used it. I rely on my iptables rules instead.
>>> 
>> 
>> OK, I used this in my fw-script:
>> 
>> echo "1" > /proc/sys/net/ipv4/tcp_syncookies
>> echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
>> echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
>> echo "5" > /proc/sys/net/ipv4/icmp_ratelimit
>> echo "0" > /proc/sys/net/ipv4/tcp_ecn
>> 
>> for if in  $IF ; do
>>        echo "1" > /proc/sys/net/ipv4/conf/$if/rp_filter
>>        echo "0" > /proc/sys/net/ipv4/conf/$if/accept_redirects
>>        echo "0" > /proc/sys/net/ipv4/conf/$if/accept_source_route
>>        echo "0" > /proc/sys/net/ipv4/conf/$if/bootp_relay
>>        echo "1" > /proc/sys/net/ipv4/conf/$if/log_martians
>> done
>> 
>> But: disabling this, restarting network -> no changes (with values
> from 
>> /proc/sys/net/ipv4/conf/default/)
>> 
>>> Do you have any PREROUTING DNAT rules that could be natting your
> packets 
>>> incorrectly so you don't see them with your dest based log rules?
>>> 
>> No.
>> 
>>> You ain't doing any other fancy policy routing via iproute2, that
> isn't 
>>> seen in you normal routing table?
>>> 
>> [root@host root]# ip route
>> <ppp-gw> dev ppp0  proto kernel  scope link  src <pip>
>> 10.129.0.1 dev tun0  proto kernel  scope link  src 10.129.0.2 
>> 10.128.0.0/24 via 10.129.0.1 dev tun0 
>> 169.254.0.0/16 dev eth0  scope link 
>> 192.168.0.0/16 dev eth0  proto kernel  scope link  src 192.168.0.254 
>> default via <ppp-gw> dev ppp0 
>> 
>> 
>> 
>>> To make absolutly sure it's not a firewall issue, would it be
> possible to 
>>> try running without any rules, or with defauly policy ALLOW and just
> one
>>> blocking rule denying traffic from the internet interface?
>>> 
>> I tried without:
>> 
>> [root@host root]# iptables -L
>> Chain INPUT (policy ACCEPT)
>> target     prot opt source               destination         
>> 
>> Chain FORWARD (policy ACCEPT)
>> target     prot opt source               destination         
>> 
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination         
>> 
>> Chain my_drop (0 references)
>> target     prot opt source               destination         
>> 
>> Chain my_log (0 references)
>> target     prot opt source               destination   
>> 
>> 
>> [root@firefly root]# iptables -L -t nat
>> Chain PREROUTING (policy ACCEPT)
>> target     prot opt source               destination         
>> 
>> Chain POSTROUTING (policy ACCEPT)
>> target     prot opt source               destination         
>> SNAT       all  --  anywhere             anywhere
> to:217.140.81.31 
>> 
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination   
>> 
>> 
>>> One thing I'm a little uncertain about is whether the packets can be
> seen 
>>> on tun0 regardless of if any userspace application is processing the 
>>> packets or not. My previous assumptions are made on that you can
> always 
>>> see the packets on tun0 if the kernel is routing properly even if
> OpenVPN 
>>> is not running at all. If this is not case, then we should perhaps
> move on 
>>> and have a look at your openvpn configs.
>> 
>> I am not sure about this. Here are my configs:
>> 
>> GW2:
>> ----
>> dev tun
>> 
>> # Our OpenVPN peer is the office gateway.
>> remote <pip1>
>> 
>> # 10.1.0.2 is our local VPN endpoint (home).
>> # 10.1.0.1 is our remote VPN endpoint (office).
>> ifconfig 10.129.0.2 10.129.0.1
>> 
>> up ./office.up
>> 
>> # Our pre-shared static key
>> secret office.key
>> 
>> 
>> GW1:
>> ----
>> dev tun
>> 
>> # peers adress
>> remote <pip2>
>> 
>> # 10.1.0.1 is our local VPN endpoint (office).
>> # 10.1.0.2 is our remote VPN endpoint (home).
>> ifconfig 10.129.0.1 10.129.0.2
>> 
>> # Our up script will establish routes
>> # once the VPN is alive.
>> up ./home.up
>> 
>> # Our pre-shared static key
>> secret home.key
>> 
>> 
>> VERY simple, isn't it. Really strange. 
>> 
>> 
> SHAME ON ME! I finally solved this one. SHAME ON ME!
> 
> I tried IPSec before and forgot to flush all entries. Argh.
> 
>  This is a nice prove
> for the usability OpenVPN, since it is better to debug and much easier
> to
> configure. 
> 
> However, I think this thread is not useless, since it provides
> some starting points for routing debuggers :)
> 
> Thanks a lot Mathias and if it ever happens, that You would like to get
> some pizza, just drop me an email...;)
> 
>> 
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive
> Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl



____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users