|
|
Kate Kretz wrote:
> tell us more about server side:
>
> NIC ?
> OS ?
Linux FC2.
> how bridge is implemented ?
br0 Link encap:Ethernet HWaddr 00:C0:9F:46:48:06
inet addr:192.168.141.3 Bcast:192.168.141.255 Mask:255.255.255.0
inet6 addr: fe80::2c0:9fff:fe46:4806/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2501 errors:0 dropped:0 overruns:0 frame:0
TX packets:3309 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:314969 (307.5 Kb) TX bytes:532775 (520.2 Kb)
eth0 Link encap:Ethernet HWaddr 00:C0:9F:46:48:06
inet6 addr: fe80::2c0:9fff:fe46:4806/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:2086353 errors:0 dropped:0 overruns:0 frame:0
TX packets:2691500 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:728607788 (694.8 Mb) TX bytes:2836704218 (2705.2 Mb)
Base address:0xece0 Memory:fe1e0000-fe200000
[root@kahn root]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.128.141 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.9.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
192.168.128.0 192.168.128.141 255.255.255.0 UG 0 0 0 tun0
192.168.141.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
0.0.0.0 192.168.141.2 0.0.0.0 UG 0 0 0 br0
On the server end, tcpdump shows arp looking for the laptop.
On the laptop end, wireshark shows arp looking for the server.
No data flows either way.
I've posted logs from the laptop at
http://www.seiner.com/tnd/log.odt
http://www.seiner.com/tnd/log1.odt
The laptop admin is looking for the MS patch for this:
http://support.microsoft.com/kb/913522/en
MS still has not responded to his request from yesterday morning.
This is the script I am using to bring up the bridge:
#!/bin/bash
#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################
# Define Bridge Interface
br="br0"
# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"
# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="192.168.141.3"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.141.255"
for t in $tap; do
openvpn --mktun --dev $t
done
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
brctl addif $br $t
done
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
route -n | grep $eth | grep 255\.255\.255\.0 | awk '{print "route del
-net " $1 " netmask " $3 " dev '"$eth"';" }'
route -n | grep $eth | grep 255\.255\.255\.255 | awk '{print "route del
-host " $1 " netmask " $3 " dev '"$eth"';" }'
route add default gw 192.168.141.2
--Yan
>
> after tunnel is established, can You try to ping client (from server)
> while running wireshark on the client side ?
>
> On 11/7/07, *Yan Seiner* <yan@xxxxxxxxxx <mailto:yan@xxxxxxxxxx>> wrote:
>
> David Balazic wrote:
> > Does the client run with administrator rights ?
> >
> > I believe this line in the server config is unneeded :
> > push "route 192.168.141.0 <http://192.168.141.0> 255.255.255.0
> <http://255.255.255.0>"
>
> We've checked - it runs with administrator rights (it can create
> the tap
> device) and I've removed teh offending line; no joy. Tunnel is
> created,
> no traffic flows, no gateway for tap device.
>
> :-(
>
> Do we need to add route-delay 60 or something to the client?
>
> Is there a script or something we can use to create it 'by hand' after
> the connection is up?
>
> --Yan
>
> >
> > Regards,
> > David
> >
> > *From:* openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx
> <mailto:openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx> on behalf of Yan
> > Seiner
> > *Sent:* Wed 07-Nov-07 03:41
> > *To:* openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> <mailto:openvpn-users@xxxxxxxxxxxxxxxxxxxxx>
> > *Cc:* Johan Niemand
> > *Subject:* [Openvpn-users] route not being pushed to client
> >
> > We're trying to bridge a linux box to a windows road warrior.
> >
> > We need to bridge because of some software on the road warrior that
> > won't work with routed networks.
> >
> > So far we've established the tunnel and we can get an IP, but no
> data
> > flows. No pings, no nothing.
> >
> > We've figured out that this is most likely due to to gateway not
> being
> > pushed to the client. I've posted a screenshot at
> > http://www.seiner.com/screenshot.png
> >
> > From the manpage,
> >
> > server-bridge gateway netmask pool-start-IP pool-end-IP
> >
> > For example, server-bridge 10.8.0.4
> <http://10.8.0.4> 255.255.255.0 <http://255.255.255.0>
> > 10.8.0.128 <http://10.8.0.128>
> > 10.8.0.254 <http://10.8.0.254> expands as follows:
> >
> > mode server
> > tls-server
> >
> > ifconfig-pool 10.8.0.128 <http://10.8.0.128>
> 10.8.0.254 <http://10.8.0.254> 255.255.255.0 <http://255.255.255.0>
> > push "route-gateway 10.8.0.4 <http://10.8.0.4>"
> >
> > So the client should get a default route of 10.8.0.4
> <http://10.8.0.4>
> >
> > On our system, the route for the tap interface is set but the
> default
> > gateway for the tap adapter remains empty, and the default route
> is set
> > to the physical NIC.
> >
> > Can anyone suggest what we need to set, for either the client or
> the
> > server?
> >
> > Server conf:
> > port 1194
> > proto tcp
> > dev tap
> > ca /etc/openvpn/easy-rsa/keys/ca.crt
> > cert /etc/openvpn/easy-rsa/keys/server.crt
> > key /etc/openvpn/easy-rsa/keys/server.key
> > dh /etc/openvpn/easy-rsa/keys/dh1024.pem
> > ifconfig-pool-persist ipp.txt
> > server-bridge 192.168.141.3 <http://192.168.141.3> 255.255.255.0
> <http://255.255.255.0> 192.168.141.120 <http://192.168.141.120>
> 192.168.141.127 <http://192.168.141.127>
> > push "route 192.168.141.0 <http://192.168.141.0> 255.255.255.0
> <http://255.255.255.0>"
> > keepalive 10 120
> > comp-lzo
> > persist-key
> > status openvpn-status.log
> > verb 3
> >
> > client conf:
> > client
> > dev tap
> > proto tcp
> > remote x.x.x.x 1194
> > resolv-retry infinite
> > nobind
> > persist-key
> > persist-tun
> > ca ca.crt
> > cert tiffini.crt
> > key tiffini.key
> > comp-lzo
> > verb 3
> >
> > Thanks,
> >
> > --Yan
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a
> browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Openvpn-users mailing list
> > Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> <mailto:Openvpn-users@xxxxxxxxxxxxxxxxxxxxx>
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> <mailto:Openvpn-users@xxxxxxxxxxxxxxxxxxxxx>
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>
>
> !DSPAM:4732ae9664846688015979!
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|
