Can't access server from outside (internet-red)

[Guest]

[koukobin]

Do you have the ips enabled? I had the same problem (i was able to ping all the systems, i was able to access web servers, but windows file sharing was not working).

Finally i had to disable some rules in the ips and everything was fine after that.

The strange thing was that the ips log was clear. IPS was blocking the file sharing but didn't log this action.

If your ips is enable try to disable it and try again.

[dammit]

it's already disabled...

i've looked at the logs:

Apr 6 14:50:43     local      OpenVPN 2.1_rc15 i586-pc-linux [SSL] [LZO2] [EPOLL] built on Aug 11 2009
Apr 6 14:50:43    local    NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Apr 6 14:50:43    local    NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 6 14:50:43    local    NOTE: --script-security method='system' is deprecated due to the fact that passed parameters will be subject to shell expansion
Apr 6 14:50:43    local    WARNING: POTENTIALLY DANGEROUS OPTION --client-cert-not-required may accept clients which do not present a certificate
Apr 6 14:50:43    local    TUN/TAP device tap0 opened
Apr 6 14:50:43    local    GID set to openvpn
Apr 6 14:50:43    local    UID set to openvpn
Apr 6 14:50:43    local    UDPv4 link local (bound): [undef]:1194
Apr 6 14:50:43    local    UDPv4 link remote: [undef]
Apr 6 14:50:43    local    Initialization Sequence Completed
Apr 6 14:50:59    local    event_wait : Interrupted system call (code=4)
Apr 6 14:50:59    local    OpenVPN CLIENT LIST
Apr 6 14:50:59    local    Updated,Tue Apr 6 14:50:59 2010
Apr 6 14:50:59    local    Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
Apr 6 14:50:59    local    ROUTING TABLE
Apr 6 14:50:59    local    Virtual Address,Common Name,Real Address,Last Ref
Apr 6 14:50:59    local    GLOBAL STATS
Apr 6 14:50:59    local    Max bcast/mcast queue length,0
Apr 6 14:50:59    local    END

only thing wrong that I found is that in bold, although I couldn't find anything about it...

[mrkroket]

The basic steps on testing an OpenVPN connection:

1- Check the server is running
2- On Server: Check that VPN Firewall is correctly setup.
3- Check if client connects. With OpenVPN Client on Windows you'll see a green icon on taskbar.
4- On Client: Check that your TUN/TAP interface has a correct IP from your EFW Green Network.
5- On Client: Traceroute to EFW Firewall. As it seems you are able to get that.
6- On Server: Check that you are pushing your networks. It's on VPN->OpenVPN Server->Push these networks: 192.168.100.0/24. Restart.
7- On Client: Try a Traceroute to another pc on GREEN. It should reach it on one step, if on tracert appears more than one jump, the traffic probably isn't going inside the VPN tunnel. Post the results of tracert 192.168.100.101 here. Ping is useful, but very broad. Tracert gives you better info about what's going on with your traffic.

[dammit]

i did that...results are:

tracert to endian (192.168.100.3)

Code:

Tracing route to 192.168.100.3 over a maximum of 30 hops

  1    71 ms    73 ms    73 ms  192.168.100.3

Trace complete.

tracert to one lan pc (192.168.100.102)

Code:

Tracing route to 192.168.100.102 over a maximum of 30 hops

  1  My-PC [192.168.100.160]  reports: Destination host unreachable.

Trace complete.

the ip 192.168.100.160 is the ip assigned by endian to the tap client...



ipconfig from client:

Code:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Win32 Adapter V8
   Physical Address. . . . . . . . . : 00-FF-E8-D7-A2-5D
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::a567:185c:d8f4:d48d%13(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.100.160(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : monday, 12 april 2010 23:47:
57
   Lease Expires . . . . . . . . . . : tuesday, 12 april 2011 23:47:58

   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 192.168.100.0
   DHCPv6 IAID . . . . . . . . . . . : 402718696
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-0D-FD-70-00-1E-8C-77-F0-D4

   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Atheros L1 Gigabit Ethernet 10/100/1000Ba
se-T Controller
   Physical Address. . . . . . . . . : 00-1E-8C-77-F0-D4
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::b96d:df92:cacc:3ae7%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.182(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : monday, 12 april 2010 23:36:
25
   Lease Expires . . . . . . . . . . : monday, 19 april 2010 23:36:
25
   Default Gateway . . . . . . . . . : 192.168.0.1
   DHCP Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6 IAID . . . . . . . . . . . : 234888844
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-0D-FD-70-00-1E-8C-77-F0-D4

   DNS Servers . . . . . . . . . . . : 200.204.0.10
                                       192.168.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{B2AFE3A9-E0E3-46E9-BDD2-CA0E6423F648}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Local Area Connection* 9:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:8d5:24e1:36f2:58a1(Prefe
rred)
   Link-local IPv6 Address . . . . . : fe80::8d5:24e1:36f2:58a1%12(Preferred)
   Default Gateway . . . . . . . . . : ::
   NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter isatap.{E8D7A25D-9E50-4200-BAD5-6F51AAB215B7}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Log from client:

Code:

Mon Apr 12 23:47:47 2010 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Mon Apr 12 23:47:55 2010 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Mon Apr 12 23:47:55 2010 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mon Apr 12 23:47:55 2010 LZO compression initialized
Mon Apr 12 23:47:55 2010 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Apr 12 23:47:55 2010 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Apr 12 23:47:55 2010 Local Options hash (VER=V4): 'd79ca330'
Mon Apr 12 23:47:55 2010 Expected Remote Options hash (VER=V4): 'f7df56b8'
Mon Apr 12 23:47:55 2010 UDPv4 link local: [undef]
Mon Apr 12 23:47:55 2010 UDPv4 link remote: ***.**.204.225:1194
Mon Apr 12 23:47:55 2010 TLS: Initial packet from ***.**.204.225:1194, sid=2205ae16 b111ef91
Mon Apr 12 23:47:56 2010 VERIFY OK: depth=1, /C=IT/O=efw/CN=efw_CA
Mon Apr 12 23:47:56 2010 VERIFY OK: depth=0, /C=IT/O=efw/CN=127.0.0.1
Mon Apr 12 23:47:56 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Apr 12 23:47:56 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 12 23:47:56 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Apr 12 23:47:56 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 12 23:47:56 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Apr 12 23:47:56 2010 [127.0.0.1] Peer Connection Initiated with  ***.**.204.225:1194
Mon Apr 12 23:47:57 2010 SENT CONTROL [127.0.0.1]: 'PUSH_REQUEST' (status=1)
Mon Apr 12 23:47:57 2010 PUSH: Received control message: 'PUSH_REPLY,ifconfig 192.168.100.160 255.255.255.0,route 192.168.100.0 255.255.255.0,ping-restart 30,ping 8,route-gateway 192.168.100.3,route 192.168.100.0 255.255.255.0,route-gateway 192.168.100.3'
Mon Apr 12 23:47:57 2010 OPTIONS IMPORT: timers and/or timeouts modified
Mon Apr 12 23:47:57 2010 OPTIONS IMPORT: --ifconfig/up options modified
Mon Apr 12 23:47:57 2010 OPTIONS IMPORT: route options modified
Mon Apr 12 23:47:57 2010 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{E8D7A25D-9E50-4200-BAD5-6F51AAB215B7}.tap
Mon Apr 12 23:47:57 2010 TAP-Win32 Driver Version 8.4 
Mon Apr 12 23:47:57 2010 TAP-Win32 MTU=1500
Mon Apr 12 23:47:57 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.100.160/255.255.255.0 on interface {E8D7A25D-9E50-4200-BAD5-6F51AAB215B7} [DHCP-serv: 192.168.100.0, lease-time: 31536000]
Mon Apr 12 23:47:57 2010 Successful ARP Flush on interface [13] {E8D7A25D-9E50-4200-BAD5-6F51AAB215B7}
Mon Apr 12 23:47:59 2010 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Mon Apr 12 23:47:59 2010 route ADD 192.168.100.0 MASK 255.255.255.0 192.168.100.3
 OK!
Mon Apr 12 23:47:59 2010 route ADD 192.168.100.0 MASK 255.255.255.0 192.168.100.3
The route addition failed: The object already exists.
Mon Apr 12 23:47:59 2010 Initialization Sequence Completed

log from endian:

Code:

Apr 12 23:41:31  	local  	 ***.**.173.172:61205 Re-using SSL/TLS context
Apr 12 23:41:31 	local 	 ***.**.173.172:61205 LZO compression initialized
Apr 12 23:41:32 	local 	 ***.**.173.172:61205 [teste] Peer Connection Initiated with  ***.**.173.172:61205 (via  ***.**.204.225)
Apr 12 23:47:54 	local 	 ***.**.173.172:62059 Re-using SSL/TLS context
Apr 12 23:47:54 	local 	 ***.**.173.172:62059 LZO compression initialized
Apr 12 23:47:55 	local 	 ***.**.173.172:62059 [teste] Peer Connection Initiated with  ***.**.173.172:62059 (via  ***.**.204.225)

I noticed that on TAP client, the gateway is not assigned, so I tried to manually configure it rather than obtaining it from DHCP, but the results were:

Code:

Tracing route to 192.168.100.102 over a maximum of 30 h

  1    74 ms    71 ms    73 ms  192.168.100.3
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

[dammit]

also there's a lot of pages like this on endian's firewall log:

[mrkroket]

Good and bad news:

Good News: Your traffic is being routing OK, so your VPN in fact is OK
Bad News: You still can connect to your PC.

You don't need a Gateway on TAP interface, in fact is better not to have one, since subnet 192.168.100.0 is local to you.

Just to check:
1-Ensure both PC can reply to ping. Double check that isn't a Windows Firewall problem. It happens to me a  of times that problems relies on something totally different. Try to ping from your Endian Firewall console to 192.168.100.102. If that doesn't work, you have blocked the ping reply on the .102 PC. See http://www.sysprobs.com/enable-ping-reply-windows-7 and on Control Panel->Firewall->Advanced->ICMP->Allow incoming echo request. Disable Windows Firewall on both machines.
2-Try the reverse ping/traceroute, from .102 to .160.
3- On your last log I don't see any ICMP traffic. On VPN Firewall disable all logs, and create a 1st position rules to accept and log traffic from protocol ICMP on both directions, first rule from Any VPN User to GREEN and second rule viceversa.

[dammit]

I just found the problem: promiscuous mode was rejected on the VMWare Vswitches! I allowed it and now VPN clients are able to see and access all LAN PCs.

Thanks for mkroket and everyone else who helped here in this topic! 

[raneesh]

which version of endian you are using?

[mrkroket]

I just found the problem: promiscuous mode was rejected on the VMWare Vswitches! I allowed it and now VPN clients are able to see and access all LAN PCs.

Thanks for mkroket and everyone else who helped here in this topic! 

Hmmm, you never mentioned you have a virtualization layer.
That complexes the whole thing adding another test points.

Well, whatever, grats to resolve by yourself.