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

Re: [Openvpn-users] Can ping across to LAN, but no http, mail, etc.


  • Subject: Re: [Openvpn-users] Can ping across to LAN, but no http, mail, etc.
  • From: Jefferson Wagener <jefferson@xxxxxxxxxxx>
  • Date: Sat, 1 Jan 2005 11:19:56 -0500


Running openvpn2.0rc1

Have a link up in server-client ala the sample files.

Can ping both the remote gateway (e.g. 192.168.1.1) and other machines
on the remote lan (e.g. 192.168.1.2) from the client (e.g. 192.168.2.1)
Can resolve DNS from remote gateway.
Can see the webserver on the gateway (e.g.192.168.1.1)


But:
Can't see the webserver on other machines (e.g. 192.168.1.2), even tho'
ping works.


I don't have ethernet bridging on, but didn't think I needed it for
this.
I have run both udp and tcp connections
The gateway is running iptables with outbound permissive

Suggestions? This is probably something simple...

Can't reach via IP address or name?

Traceroute tp the IP then to the name if you are trying this.

Can you telnet to the port and get a response?

--
Leonard Isham, CISSP
Ostendo non ostento.


Right. Let me try an give some more detailed info here:

Setup:
Client (NATed to 10.0.1.2, OpenVPN Assigns LAN IP of 172.16.2.2)
|
Router/Home Gateway (Dynamic IP)
|
|
|
Methuselah (my.real.ip.addr on eth0, 172.16.1.1 on eth1, OpenVPN assigns 172.16.2.1)
|
Prometheus (172.16.1.2)


Goal:
Access web server on prometheus from client

Problem:
Can ping prometheus, but no http.

Output snippets, with OpenVPN up:
*********************************
client> ifconfig
tap0: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500
        inet 172.16.2.2 netmask 0xffffff00 broadcast 172.16.2.255
        ether 74:61:70:00:00:00
        open (pid 602)

methuselah> ifconfig
tap0      Link encap:Ethernet  HWaddr 00:FF:87:00:90:BE
          inet addr:172.16.2.1  Bcast:172.16.2.255  Mask:255.255.255.0
          inet6 addr: fe80::2ff:87ff:fe00:90be/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6936 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4428 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:539684 (527.0 KiB)  TX bytes:812674 (793.6 KiB)

client> ping 172.16.2.1 #ping the OpenVPN interface of the server
PING 172.16.2.1 (172.16.2.1): 56 data bytes
64 bytes from 172.16.2.1: icmp_seq=0 ttl=64 time=98.543 ms

client> ping 172.16.1.1 #ping the eth1 interface of the server, on LAN
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=45.978 ms

client> ping 172.16.1.2 #ping prometheus, on LAN
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=63 time=59.167 ms

client> traceroute 172.16.1.1 #trace to the eth1 of methuselah, the OpenVPN server
traceroute to 172.16.1.1 (172.16.1.1), 30 hops max, 40 byte packets
1 methuselah.mydomain.com (172.16.1.1) 42.677 ms 49.906 ms 136.441 ms


client> traceroute 172.16.1.2 #trace to prometheus
traceroute to 172.16.1.2 (172.16.1.2), 30 hops max, 40 byte packets
 1  172.16.2.1 (172.16.2.1)  88.071 ms  42.745 ms  64.88 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  *^C

methuselah> traceroute 172.16.2.2 #trace back to client from server
traceroute to 172.16.2.2 (172.16.2.2), 30 hops max, 38 byte packets
 1  172.16.2.2 (172.16.2.2)  156.715 ms  134.620 ms  31.698 ms

methuselah> traceroute 172.16.1.2 #trace to prometheus from methuselah
traceroute to 172.16.1.2 (172.16.1.2), 30 hops max, 38 byte packets
 1  prometheus.mydomain.com (172.16.1.2)  0.767 ms  0.659 ms  0.480 ms


client> netstat -rt #the routes on the client, which look fine...
Destination Gateway Flags Refs Use Netif Expire
default 10.0.1.1 UGSc 20 1 en1
10.0.1/24 link#5 UCS 2 0 en1
10.0.1.1 0:3:93:e2:68:9e UHLW 19 4954 en1 1079
10.0.1.2 localhost UHS 0 1 lo0
10.0.1.255 link#5 UHLWb 1 6 en1
127 localhost UCS 0 0 lo0
localhost localhost UH 50 125721 lo0
169.254 link#5 UCS 0 0 en1
172.16.1/24 172.16.2.1 UGSc 2 8 tap0
172.16.2/24 link#7 UC 3 0 tap0
172.16.2.1 0:ff:87:0:90:be UHLW 2 3 tap0 1006
172.16.2.255 link#7 UHLWb 1 8 tap0


methuselah> netstat -rt #the routes on the server, these also look fine to me...
Destination Gateway Genmask Flags MSS Window irtt Iface
my.real.ip.0 * 255.255.255.224 U 0 0 0 eth0
172.16.2.0 * 255.255.255.0 U 0 0 0 tap0
172.16.1.0 * 255.255.255.0 U 0 0 0 eth1
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
default my.real.ip.gateway 0.0.0.0 UG 0 0 0 eth0


methuselah> iptables-save #I've only put a couple lines of iptables here, not all...
#OpenVPN stuff
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -i tap+ -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT
-A OUTPUT -o tap+ -j ACCEPT
#We are NATing (are THESE lines the issue?, are we somehow remapping ports, from tap0?)
-A FORWARD -d 172.16.1.0/255.255.255.0 -p tcp -m tcp --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 172.16.1.0/255.255.255.0 -p udp -m udp --dport 1023:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT


*********************************
The web server running on methuselah (gateway & VPN server, 172.16.1.1) can be seen by the client.
The web server running on 172.16.1.2 can not be seen by the client.


OK, hopefully that was a lot more detailed info, and we can shed some light on this now...
Happy new year!
Jeff




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users