Thread Info
  • State Not Answered
  • Replies 16 replies
  • Subscribers 0 subscribers
  • Views 4972 views
  • Users 0 members are here
Options
Suggested

"Default Drop" of HTTPS packets on internal connection

mhibler
Hi guys,

Here's another one from my workshop [;)]

I have an ASG v8 as a virtual appliance (192.168.98.254) on a ESXi host (192.168.98.1).

I can not connect to the ESXi host with VMware vSphere Client from another internal PC (192.168.98.11).

Here's a Packet Filter log:


2010:08:16-03:05:13 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="40" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK" 
2010:08:16-03:05:13 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="110" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK PSH" 
2010:08:16-03:05:16 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="110" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK PSH" 
2010:08:16-03:05:16 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="40" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK" 
2010:08:16-03:05:22 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="110" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK PSH" 
2010:08:16-03:05:22 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="40" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK" 
2010:08:16-03:05:34 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="110" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK PSH" 
2010:08:16-03:05:34 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="40" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK" 
2010:08:16-03:05:43 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="40" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK FIN" 
2010:08:16-03:05:46 vmaastaro ulogd[3728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:e:7f:23:84:bb" dstmac="0:c:29:4a:f5:18" srcip="192.168.98.11" dstip="192.168.98.1" proto="6" length="110" tos="0x00" prec="0x00" ttl="128" srcport="3028" dstport="443" tcpflags="ACK PSH FIN" 
However, on a very rare occasion I do manage to connect just to be disconnected a couple of minutes later.

I have another ESXi host on the same network (192.168.98.2) which is working just fine...

What should I check?

Thanks in advance,

Miro
  • 0
    I suppose you could make a packet filter rule: 'Internal (Network) -> Any -> Internal (Network) : Allow', but I'm confused as to why .98.11 would have to transit Astaro to reach .98.1 - Is the Astaro running in bridge mode?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Hi again, Bob! [:)]

    I suppose you could make a packet filter rule: 'Internal (Network) -> Any -> Internal (Network) : Allow'...
    Trust me, I tried everything I could think of (yes, even 'Any -> Any -> Any : Allow')...

    ...but I'm confused as to why .98.11 would have to transit Astaro  to reach .98.1 - Is the Astaro running in bridge mode?
    Nope ('No bridge is currently configured'). That puzzles me even more...

    And I even had to create some other rules ('Internal (Network) ->  **** -> Internal (Network)') to make some other applications work  internally (WTF?), but since it solved the problem, I didn't question it any more...

    But, if all traffic is eventually routed via ASG, why .98.11 has no problem reaching .98.2 (the other ESXi)?

    Is it something to do with configuration of virtual network on .98.1  ESXi (a wild guess...)? Or maybe a network configuration at .98.11  ('Default router' - which is .98.254 - ASG...)?

    Otherwise, the ASG is working pretty fine - Remote Access, VPN, some other PF rules - all working fine ...

    Thanks,

    Miro
  • 0
    General philosophy for Astaro: an arriving packet is first considered by DNATs, then by Proxies, then by manual routes and, finally, by SNATs.

    I'm guessing that the vShpere Client is running on port-443 and that you have the HTTP/S Proxy in Transparent mode and are scanning SSL traffic.  If that's the case, then try putting the target server into the 'Transparent mode skiplist'.  If you're not in a transparent mode, then skipping the proxy for local IPs has to be done with wpad or a GPO.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    ...I'm guessing that the vShpere Client is running on port-443 and that you have the HTTP/S Proxy in Transparent mode and are scanning SSL traffic...


    Bob, this is Essential Firewall Edition - HTTP/S Proxy is disabled (as a matter of fact, it shows green light - greyed out, though - and I'm getting the 'Licensing Info - Web Security HTTP/S is disabled as you do not have a subscription or your subscription is expired!' message on top of the page)... [H]

    So, no fiddling there...

    Miro
  • 0
    You know, I just don't know enough about VMWare, but it seems like your issue must be related to how you have IPs and routes configured in it.  It's just not normal that traffic between two "devices" in the same subnet would transit the Astaro.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Now, if I could only connect to ESXi server to check/change networking... [;)]

    Many thanks anyway!

    Miro
  • 0 in reply to mhibler
    A few days ago I activated the transparent HTTP and HTTPS proxy, then disabled it and could not use any connection on port 80 or 443 any more as those got ignored by any NAT rule. As a result all packets to port 80 or 443 got routed through the default gateway which was the wrong destination for example for some servers in a DMZ.

    using 7.508
  • 0
    I'm not sure I understand your issue, but maybe this KnowledgeBase article will help: https://support.astaro.com/support/index.php/Accessing_Internal_or_DMZ_Webserver_from_Internal_network

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    BAlfson, the transparent proxy was only temporary enabled and after it was disabled the internal  NAT rule for port http and https stayed in the system. Only when I did a restart of the Astaro system it went away and access was possible again also for ports http and https.
  • 0
    The next time you have the same issue, try flushing the DNS cache of the Astaro and or your client.  It's still not clear to me what you observed, but, if it's working, all's well that ends well! [;)]

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA