|
|
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 ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |