Page 1 of 2

Gargoyle NAT 'leaking' port 443?

Posted: Mon Mar 07, 2016 3:18 pm
by sigwx
Hello

Hoping I can describe this without pictures, we will see...

So, my provider's equipment has a firewall built in that I've disabled -except- that all outbound traffic must come from the IP of the Gargoyle router (to prevent people from removing the Gargoyle router and plugging something else in). Since that's the only device attached to the provider's equipment shouldn't be a problem.

I happened to review the firewall logs on the provider's equipment, and interestingly enough, I'm seeing lots of dropped packets, all with source IPs from the Gargoyle's private network and -only- for things going to port 443. For example:
TCP Packet - Source:192.168.1.33,52167 Destination:xxx.xxx.xxx.xxx,443, 10:59:04, 2016-03-07

Why would anything from the Gargoyle router go out to the 'public' side with a private IP address on it? Or is there a known issue here? I use HTTPS sites all the time, and they work, so I don't think all packets have this issue (or I'd not be able to get to any HTTPS site) but something odd is happening.

Wondering if this could be a problem in how I have Gargoyle configured but I don't know where it would be.

I'm more than happy to setup some test/debug/dump firewall rules/configs/etc if that helps solve the problem (if there is one). I'm currently running 1.9.0 with a Netgear WNDR3800.

Thanks!

Re: Gargoyle NAT 'leaking' port 443?

Posted: Mon Mar 07, 2016 4:22 pm
by nworbnhoj
Thank you for reporting - doesn't seem right at all.

What parts of Gargoyle are you using? Have you configured any port forwarding? do you use any plugins? what other config do you use?

Re: Gargoyle NAT 'leaking' port 443?

Posted: Mon Mar 07, 2016 10:51 pm
by sigwx
Well, here's a summary of what I've been using.

I have PortForwarding of ssh inbound to an internal server, nothing else. DMZ is disabled.

QOS is enabled, I can give specifics but I got the info from a page here (Both up and down, Fast with 512 byte pkt len, then a Normal, then a Throttled with bandwidth limits that are used by Quotas, Active Congestion Control enabled on the download side).

Quotas are enabled, two group based sets and a per IP default for the rest.

OpenVPN server is also enabled, but rarely used.

No 'extra' plugins installed other than what came with 1.9.0.

Thanks

Re: Gargoyle NAT 'leaking' port 443?

Posted: Wed Mar 09, 2016 1:02 am
by Eric
Hmm.. I don't see that as something that is a security issue, but it just shouldn't be happening. NAT should prevent the addresses from being visible there, because they are literally over-written in the connection when they are NATed. I'm confused how there is any sort of connection at all in that case.

Re: Gargoyle NAT 'leaking' port 443?

Posted: Wed Mar 09, 2016 8:35 am
by roadhawk
You could turn QoS, Quotas and OpenVPN off and see if this behavior stops, and let us know what happened.

Re: Gargoyle NAT 'leaking' port 443?

Posted: Wed Mar 09, 2016 12:22 pm
by sigwx
Yeah, figured that so taking one service at a time. So far, removing QoS didn't make the problem go away.

Re: Gargoyle NAT 'leaking' port 443?

Posted: Wed Mar 09, 2016 11:47 pm
by sigwx
Well, dropped everything from that list, still seeing the odd 443 traffic.
Would having a WiFi guest network change anything? It doesn't have anything attached, will try turning that off next.

Re: Gargoyle NAT 'leaking' port 443?

Posted: Thu Mar 10, 2016 3:01 am
by roadhawk
What are the IPs of your two routers?
Also, see PM.

Re: Gargoyle NAT 'leaking' port 443?

Posted: Thu Mar 10, 2016 1:18 pm
by sigwx
Goes something like:

'internet' <-> (xx.xx.xx.xx) provider's router (10.0.0.1) <-> (10.0.0.3) Gargoyle router (192.168.1.2) <-> (192.168.1.x) private lan

Re: Gargoyle NAT 'leaking' port 443?

Posted: Mon Mar 14, 2016 12:54 pm
by Eric
Before digging too much further here, I think it's important to look at the behavior of other routers.

It's true, I'm not sure where that information would be stored or how it would be captured in a NATed connection, but I'd like to verify that this doesn't happen with either a default/vanilla install of OpenWRT or a stock wireless router, that your test setup isn't capturing something that would be present on any valid NATed connection.