|
|
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.
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?
You ain't doing any other fancy policy routing via iproute2, that isn't
seen in you normal routing table?
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?
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.
--
_____________________________________________________________
Mathias Sundman (^) ASCII Ribbon Campaign
OpenVPN GUI for Windows X NO HTML/RTF in e-mail
http://www.nilings.se/openvpn / \ NO Word docs in e-mail
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|