NAT malfunction LAN on WAN

Is masquerading configured for all your LANs/DMZs?

Barry

Yes.

Network = LAN

Interface = WAN

All initially appear to be outbound to remote port 80.

Additional data:

ASG packet filter log shows [ACK RST] and the packet capture outside of the ASG shows [RST, ACK]

the long dramatic pause causes tensions to increase...the silence leaves the mind to ponder what might be happening...he patiently awaits the testing...he wonders if his installation is broken, or did he find a bug...

Hello?

Can anyone confirm my observations?



Jim

ISO roll-back install of v7.4 did not correct the problem.

Turning off HTTPS Scanning appeared to help or work...still unsure.

After upgrading to v7.401 and immediately after turning HTTPS Scanning back on, IP addresses from my LAN were captured sending [FIN, ACK] or [ACK FIN] whichever place one looks.

I have NOT conducted enough experiments to confirm anything as the cause. Just that it is still happening.

Jim, If you'd like another set of eyes on it, I can look at it for a few minutes.  Click on my name beside the avatar and email me if you like.

Cheers - Bob

I found a "work-around" that works until I figure out what is happening.

I created a catch all rule, placed it at the bottom of the packet filter rules, and set the logging option to not log. Basicly, it drops everything not explicitly allowed elsewhere.

Works so far, but I would rather have the NAT handle the ACK FIN / FIN ACK and ACK RST / RST ACK packets correctly. Or know what I did to break the ASG's NAT. 


Jim

P.S. Does anyone have a clue as to why I have this problem?

Strange that a PF rule would help, as Astaro has a default logdrop PF rule.

Barry

Yea, I thought so too. That is what is strange.  I'll keep experimenting until I can stop and then repeat the problem. 

Have you placed a sniffer in front of your ASG to watch traffic?

If anyone has any ideas, please let me know...

Jim

I'm running tcpdump on Astaro against the EXT interface now
tcpdump -ni eth0 net 192.168.0.0/16
so far I just see the cable modem (most modems have a management internal address of 192.168.100.1) arp requests.

I don't know where my hub is right now so I can't setup an independent sniffer.

Barry

...I don't know where my hub is right now so I can't setup an independent sniffer.

Barry

I suggest that you try and find the hub. Someone needs to verify the results that I will type next.

The cause of this problem is the default "Web Surfing" group that comes preset with the ASG.

Now, I believe that the original rule sequence in the "Web Surfing" group was:

HTTP
HTTP Proxy
HTTP WebCache
HTTPS

This from memory. I hope someone running pre v7.4 can confirm.

However, with the ordering problem the order of rules inside my "Web Surfing" group are currently:

HTTP Proxy
HTTPS
HTTP
HTTP WebCache

Which, if the order of rules still matters, messes the whole thing up.

NOTE: The catch all rule is ineffective when using the default "Web Surfing" group as a service.

If one pulls the rules out of the group and places them in order (as I remember) the the catch all rule must be in place to stop LAN addresses from being seen outside of the WAN interface. Otherwise a packet sniffer will see the LAN addresses outside of the ASG during [RST ACK] and [FIN ACK] packets. I believe this to be a possible stateful timeout issue with the ASG.

In an additional experiment I removed the "Web Surfing" rule(s) entirely. Access to the web is not possible unless the three proxies are on. If the HTTP, HTTPS, and FTP proxies are on, one may surf the web unhinderd, and no LAN addresses are seen outside of the ASG. FTP Connection Tracking helper must be on.

Will someone please verify my results.

I will be turning off or removing the "Web Surfing" rule and the catch all rule, which if I did not clearly state is any/any/any w/drop. Catch all logging is optional depending on whether you want to see the dropped packets or not. I will be turning on the three proxies mentioned (HTTP, HTTPS, and FTP). NOTE: In this configuration, the ASG default drop function operates correctly. However, all outgoing default drops are sent via syslog and seen in the packet filter "live log". If one does not want to see the outgoing default drops of [FIN ACK] and [RST ACK] packets, then make the catch all rule, place it at the bottom, and turn logging off. Unsolicited incoming packets are still default dropped.

I await someone to confirm or refute my claim.

Additional note: The WebCache was turned off during testing Web Security-HTTP/S-Advanced. No tests were conducted with regard to whether or not the WebCache functions.

...I don't know where my hub is right now so I can't setup an independent sniffer.

Barry

I suggest that you try and find the hub. Someone needs to verify the results that I will type next.

The cause of this problem is the default "Web Surfing" group that comes preset with the ASG.

Now, I believe that the original rule sequence in the "Web Surfing" group was:

HTTP
HTTP Proxy
HTTP WebCache
HTTPS

This from memory. I hope someone running pre v7.4 can confirm.

However, with the ordering problem the order of rules inside my "Web Surfing" group are currently:

HTTP Proxy
HTTPS
HTTP
HTTP WebCache

Which, if the order of rules still matters, messes the whole thing up.

NOTE: The catch all rule is ineffective when using the default "Web Surfing" group as a service.

If one pulls the rules out of the group and places them in order (as I remember) the the catch all rule must be in place to stop LAN addresses from being seen outside of the WAN interface. Otherwise a packet sniffer will see the LAN addresses outside of the ASG during [RST ACK] and [FIN ACK] packets. I believe this to be a possible stateful timeout issue with the ASG.

In an additional experiment I removed the "Web Surfing" rule(s) entirely. Access to the web is not possible unless the three proxies are on. If the HTTP, HTTPS, and FTP proxies are on, one may surf the web unhinderd, and no LAN addresses are seen outside of the ASG. FTP Connection Tracking helper must be on.

Will someone please verify my results.

I will be turning off or removing the "Web Surfing" rule and the catch all rule, which if I did not clearly state is any/any/any w/drop. Catch all logging is optional depending on whether you want to see the dropped packets or not. I will be turning on the three proxies mentioned (HTTP, HTTPS, and FTP). NOTE: In this configuration, the ASG default drop function operates correctly. However, all outgoing default drops are sent via syslog and seen in the packet filter "live log". If one does not want to see the outgoing default drops of [FIN ACK] and [RST ACK] packets, then make the catch all rule, place it at the bottom, and turn logging off. Unsolicited incoming packets are still default dropped.

I await someone to confirm or refute my claim.

Additional note: The WebCache was turned off during testing Web Security-HTTP/S-Advanced. No tests were conducted with regard to whether or not the WebCache functions.

Hi Jim,

I can't confirm or deny or claim, I did a tcpdump on my external interface like Barry did but  I didn't see any traffic from my lan. The only times I have seen this problem with astaro is when there is no nat masq rule configured or a cable wiring issue, I see you have created a masq rule so that doesn't appear to be the issue. It would be interesting to see what shows up in the packet filter log on the astaro, do you see any spoofing?

No spoofing.

Packet filter log should show default drops on the [FIN ACK] and [RST ACK] packets with a LAN address as the source of the packet.

2009:04:04-06:10:13 cpe-66-69-89-240 ulogd[3160]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" seq="0" initf="eth0" outitf="eth0" dstmac="00:50[:D]a:5c:68:a1" srcmac="00:50:04:ce:ee:01" srcip="192.168.7.102" dstip="66.110.201.18" proto="6" length="40" tos="0x00" prec="0x00" ttl="127" srcport="1139" dstport="80" tcpflags="ACK FIN" 
2009:04:04-06:10:16 cpe-66-69-89-240 ulogd[3160]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" seq="0" initf="eth0" outitf="eth0" dstmac="00:50[:D]a:5c:68:a1" srcmac="00:50:04:ce:ee:01" srcip="192.168.7.102" dstip="66.110.201.18" proto="6" length="40" tos="0x00" prec="0x00" ttl="127" srcport="1139" dstport="80" tcpflags="ACK FIN" 
2009:04:04-06:10:20 cpe-66-69-89-240 ulogd[3160]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" seq="0" initf="eth0" outitf="eth0" dstmac="00:50[:D]a:5c:68:a1" srcmac="00:50:04:ce:ee:01" srcip="192.168.7.102" dstip="66.110.201.18" proto="6" length="40" tos="0x00" prec="0x00" ttl="127" srcport="1139" dstport="80" tcpflags="ACK FIN" 

What I have seen is [FIN ACK] and [RST ACK] packets between the ASG and my modem with LAN addresses as the source and the desitation ip is what it should be. Indicating to me that the NAT did not translate/replace the source address of the packets into/with my WAN ip.

Meaning that there were packets being sent and probably routed that show addresses from my LAN. Not a good thing IMHO. They were probably being dropped and logged by other firewalls. Telling any observant geek (like myself) what my LAN addresses are.

Note: I have only seen the activity on [FIN ACK] and [RST ACK] packets. But they have come from all addresses on my LAN that access the internet with the exception of my DNS server. I think that is because it uses udp and not tcp (no handshake to finish and reset).

That is why one must have a sniffer immediately outside the ASG that uses a capture filter of "net 192.168" or whatever LAN address one uses to be able to confirm or refute my claim. 

As I currently have the filter rules configured, I have so far logged no LAN ip addresses as the source of a packet. With the default "Web Surfing" rule in place it is relativly frequent.

Maybe I am the only one that had the problem. What I saw was real and capturable. I would just like someone to confirm or refute the claim. Then I will know the next course of action to take.



Jim

I don't use the proxy, fwiw.

Barry

Barry, you don't use the HTTP proxy?

I don't use the proxy, fwiw.

Barry

Well, that throws a wrench in it...

I did no testing with the ASG as a configurable NAT router. (yet)

Thanks anyway.


Jim

Well Barry,

Thanks to you, I tried a test with the HTTP/S and FTP proxies turned off.

I saw the malfunction twice, then not again.

I turned to proxies back on and, TADAAAaaaaa, the problem is back. My LAN is now seen as a source outside of the ASG on [FIN ACK] packets. But this time, the catch all rule did not catch the packets.

Also, now my outbound traffic is seen via syslog. Previously, outbound traffic was not logged.

The order of rules inside the default group called "Web Surfing" is as follows:

HTTP Proxy
HTTPS
HTTP
HTTP WebCache

The proxy appears to be functional as it did block ****ography and provocative attire.

In what order should the rules be inside the "Web Surfing" group?

The problem is active. My LAN addresses are seen as source addresses outside of the ASG and the catch all rule does not stop the packets this time.



Jim

With the "Web Surfing" group rules removed, and the catch all rule off/removed...

1st test: port 80 was default dropped.

2nd test: no port 80 default drop, no lan seen as src

3rd test: same as 2nd

I cannot see the outbound traffic but no LAN adresses are seen as src outside of the ASG.

The problem is repeatable.

When closing my browser, the [ACK RST] packets are default dropped (packet filter live log). Also, the [ACK FIN] packets are default dropped. Syslog sees the packets as blocked outbound which is correct. Source addresses of packets is LAN. Since packets are default dropped, they are not seen outside of the ASG.

Normal?

Good work, Jim. I sure hope one of the Astaro developers comes by here.

Jim, the entries in the pf log that you attached are quite harmless. They also are not leaking any internal traffic out onto the internet. They are being dropped because Astaro is a fully stateful firewall. 

Whether or not this is a bug, the cause is simply that Astaro has already seen a RST packet from one end of the session, and has closed the session in its connection tracking table. Any further traffic seen for that session, is then dropped and logged - even if it is just the other side of the session trying to also close the session. Adding a pf rule to drop and not log these entries doesn't stop them from happening, just from being logged when they do.