This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN & Spoof

Hi,

I set up ssl vpn capabilities in this context :
DMZ network : 176.16.x.x
Internal : 192.168.x.x

My ssl client connect without a problem and i can do whateveer i want in the DMZ.
Now if i also want to do whatever i want in the Internal network, i have to set 
"Spoof protection" to "off".

Can i use the "Spoof protection" but still using ssl vpn to access my internal network remotly ?


This thread was automatically locked due to age.
  • Hi, it should work.

    What network address are you using for the VPN Pool?

    It should not be part of the internal or DMZ network addresses.

    Barry
  • It is not as ssl client are on the 10.242.2.x network
  • Do you have a SNAT or nat Masq for the vpn pool? 
    That might cause the spoofing, if for example you set it up to change the source to the dmz interface when you try to access the internal network it would have the wrong source address. The log entries from the packet filter would be useful to see why the packets are being dropped because of spoofing.
  • No, i only have DNAT rules for some basic traffic nature like SMTP, SMTP SSL, SFTP a HTTPS (on a specific port), and some VLC rules but nothing on VPN Pool.
    I wish to give log entries from the packet filter but if my ssl client is well connected, it has some routing errors now that make our test impossible for the moment (update : but now resolved, see the end of the post) : 

    Sat Feb 12 23:32:41 2011 OpenVPN 2.1.1 i686-pc-cygwin [SSL] [LZO2] built on May  7 2010
    Sat Feb 12 23:32:52 2011 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
    Sat Feb 12 23:32:52 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Sat Feb 12 23:32:52 2011 LZO compression initialized
    Sat Feb 12 23:32:52 2011 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
    Sat Feb 12 23:32:52 2011 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
    Sat Feb 12 23:32:52 2011 Local Options hash (VER=V4): '958c5492'
    Sat Feb 12 23:32:52 2011 Expected Remote Options hash (VER=V4): '79ef4284'
    Sat Feb 12 23:32:52 2011 Attempting to establish TCP connection with xx.xx.***.***:443
    Sat Feb 12 23:32:52 2011 TCP connection established with xx.xx.***.***:443
    Sat Feb 12 23:32:52 2011 Socket Buffers: R=[8192->8192] S=[8192->8192]
    Sat Feb 12 23:32:52 2011 TCPv4_CLIENT link local: [undef]
    Sat Feb 12 23:32:52 2011 TCPv4_CLIENT link remote: xx.xx.***.***:443
    Sat Feb 12 23:32:53 2011 TLS: Initial packet from xx.xx.***.***:443, sid=1c80757e 4752e046
    Sat Feb 12 23:32:53 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Sat Feb 12 23:32:53 2011 VERIFY OK: depth=1, /C=fr/L=***/O=***/CN=***_VPN_CA/emailAddress=***
    Sat Feb 12 23:32:53 2011 VERIFY X509NAME OK: /C=fr/L=***/O=***/CN=***/emailAddress=***
    Sat Feb 12 23:32:53 2011 VERIFY OK: depth=0, /C=fr/L=***/O=***/CN=***/emailAddress=***
    Sat Feb 12 23:32:56 2011 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
    Sat Feb 12 23:32:56 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Sat Feb 12 23:32:56 2011 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
    Sat Feb 12 23:32:56 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Sat Feb 12 23:32:56 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    Sat Feb 12 23:32:56 2011 [***] Peer Connection Initiated with xx.xx.***.***:443
    Sat Feb 12 23:32:58 2011 SENT CONTROL [***]: 'PUSH_REQUEST' (status=1)
    Sat Feb 12 23:32:58 2011 PUSH: Received control message: 'PUSH_REPLY,route remote_host 255.255.255.255 net_gateway,route 176.16.2.0 255.255.255.0,route 192.168.2.0 255.255.255.0,dhcp-option DNS 176.16.2.1,dhcp-option DNS 176.16.2.50,dhcp-option DOMAIN ***,route 10.242.2.1,topology net30,ping 10,ping-restart 120,ifconfig 10.242.2.6 10.242.2.5'
    Sat Feb 12 23:32:58 2011 OPTIONS IMPORT: timers and/or timeouts modified
    Sat Feb 12 23:32:58 2011 OPTIONS IMPORT: --ifconfig/up options modified
    Sat Feb 12 23:32:58 2011 OPTIONS IMPORT: route options modified
    Sat Feb 12 23:32:58 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
    Sat Feb 12 23:32:58 2011 ROUTE default_gateway=192.168.1.254
    Sat Feb 12 23:32:58 2011 TAP-WIN32 device [Connexion au réseau local 3] opened: \.\Global\{98AE5586-51E5-40C0-B203-04E04430161D}.tap
    Sat Feb 12 23:32:58 2011 TAP-Win32 Driver Version 9.6 
    Sat Feb 12 23:32:58 2011 TAP-Win32 MTU=1500
    Sat Feb 12 23:32:58 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.242.2.6/255.255.255.252 on interface {98AE5586-51E5-40C0-B203-04E04430161D} [DHCP-serv: 10.242.2.5, lease-time: 31536000]
    Sat Feb 12 23:32:58 2011 NOTE: FlushIpNetTable failed on interface [29] {98AE5586-51E5-40C0-B203-04E04430161D} (status=5) : Accès refusé.  
    Sat Feb 12 23:33:02 2011 TEST ROUTES: 4/4 succeeded len=4 ret=1 a=0 u/d=up
    Sat Feb 12 23:33:02 2011 C:\WINDOWS\system32\route.exe ADD xx.xx.***.*** MASK 255.255.255.255 192.168.1.254
    Sat Feb 12 23:33:02 2011 ROUTE: route addition failed using CreateIpForwardEntry: Accès refusé.   [status=5 if_index=12]
    Sat Feb 12 23:33:02 2011 Route addition via IPAPI failed [adaptive]
    Sat Feb 12 23:33:02 2011 Route addition fallback to route.exe
    Sat Feb 12 23:33:02 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
    Sat Feb 12 23:33:02 2011 C:\WINDOWS\system32\route.exe ADD 176.16.2.0 MASK 255.255.255.0 10.242.2.5
    Sat Feb 12 23:33:03 2011 ROUTE: route addition failed using CreateIpForwardEntry: Accès refusé.   [status=5 if_index=29]
    Sat Feb 12 23:33:03 2011 Route addition via IPAPI failed [adaptive]
    Sat Feb 12 23:33:03 2011 Route addition fallback to route.exe
    Sat Feb 12 23:33:03 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
    Sat Feb 12 23:33:03 2011 C:\WINDOWS\system32\route.exe ADD 192.168.2.0 MASK 255.255.255.0 10.242.2.5
    Sat Feb 12 23:33:03 2011 ROUTE: route addition failed using CreateIpForwardEntry: Accès refusé.   [status=5 if_index=29]
    Sat Feb 12 23:33:03 2011 Route addition via IPAPI failed [adaptive]
    Sat Feb 12 23:33:03 2011 Route addition fallback to route.exe
    Sat Feb 12 23:33:03 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
    Sat Feb 12 23:33:03 2011 C:\WINDOWS\system32\route.exe ADD 10.242.2.1 MASK 255.255.255.255 10.242.2.5
    Sat Feb 12 23:33:03 2011 ROUTE: route addition failed using CreateIpForwardEntry: Accès refusé.   [status=5 if_index=29]
    Sat Feb 12 23:33:03 2011 Route addition via IPAPI failed [adaptive]
    Sat Feb 12 23:33:03 2011 Route addition fallback to route.exe
    Sat Feb 12 23:33:03 2011 ERROR: Windows route add command failed [adaptive]: returned error code 1
    Sat Feb 12 23:33:03 2011 Initialization Sequence Completed

    Accès Refusé means "Access refused"
     
    EDIT : It seems i found the reason so in case it can be useful to someone : i'm under windows seven and the ssl client has to be launched with the administrator rights. I come back to the initial problem, maybe in a minute [:)]

    Ok so, i set  spoof protection to "normal" the packet filter logs gives : 
    00:11:34  Spoofed packet  TCP 
    192.168.2.100  :  443
    → 
    10.242.2.6  :  59345
    [ACK SYN]  len=52  ttl=64  tos=0x00  srcmac=0:14:fd:10:cb:a8  dstmac=0:1f[:D]0:84[:D]f[:D]b
    00:11:34  Spoofed packet  TCP 
    192.168.2.100  :  443
    → 
    10.242.2.6  :  59345

    [ACK SYN]  len=52  ttl=64  tos=0x00  srcmac=0:14:fd:10:cb:a8  dstmac=0:1f[:D]0:84[:D]f[:D]b

    Just before this, i saw that i forgot to create a packet filter rule allowing web surfing service for ssl pool, so i added it but still this changes nothing to the problem.
  • Ok, seems resolved and i feel as it were a basic solution that i should have known => i added a masquerading rule : Internal interface for VPN Pool (SSL) ...
  • Hi, normally a MASQ for VPN Pool -> EXT Interface is enough; something still seems wrong.

    Barry
  • Yes, that let me confused as something is wrong but it works [[:)]]
    At the end, i don't know what i have to do or think [[:)]]
  • barry, I am  confused.  If he is using ssl, the ext interface will never see these packets, so how would a masq rule for ext do anything?  my understanding is that a masq rule => INT will make the ssl client packets look like they came from the INT network, so the spoof stuff won't fire.  am i misunderstanding something?
  • barry, I am  confused.  If he is using ssl, the ext interface will never see these packets, so how would a masq rule for ext do anything?  my understanding is that a masq rule => INT will make the ssl client packets look like they came from the INT network, so the spoof stuff won't fire.  am i misunderstanding something?


    Yes, i have the same understanding but i'm open to explanations i look as mysterious [:)]
    For example i don't have masquerading on DMZ and it works which i look as unexpected if we continue to follow our logic.
  • Hi DSwartz & Kynao,
    Normally, MASQ is only used for traffic from the internal networks (including the VPN Pools) to the internet.

    Traffic between internal networks (and VPN Pools) does not need MASQ or NAT because the firewall already knows how to route between those networks.

    I'm assuming you have PacketFilter rules to allow the VPN Pool to access the Internal network.

    I don't know why the spoof protection is triggering though.

    Barry