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.

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.

Alan, what about his external packet capture that caught such traffic coming out the External port?

Alan, what about his external packet capture that caught such traffic coming out the External port?

Jim said he attached a packet capture, but that was just the ASG live log. 

@Jim - Do you have an external packet capture showing unmasqueraded packets leaving the Astaro? if you do not wish to post it here, you can email me directly at atoews@astaro.com

I've been able to reproduce this, but only by enabling then disabling full transparent mode. I see FIN and RST packets slip through unmasqueraded, but only for the sessions that were initiated while full transparent mode is enabled. Jim, do you have any proxy profiles setup? is it possible one of them has full transparent mode enabled?

I have neither "Full Transparent" on, nor any profiles created.

The packet capture in my initial post was from between the ASG and the modem. As you will see, the src ip is my LAN IP.

If you would like me to email you the file or make another one, let me know.


Jim

Jim, I could barely read that picture in your original post.  Maybe you could just send the Wireshark file.

Cheers - Bob

OK, file sent.

Alan,

I conducted a repeat test this morning and sent the data and explaination to you via email.


Jim

P.S. There is one packet that I failed to mention in the .pcap file. It went to "Google". I believe it was an automatic thing from the broswer.

I guess that I should also mention that I have logged many packets to JAVA (SUN/IBM). That was why I was monitoring the different LANs on the WAN. Not to mention some interesting activity from my ISPs 10/8 net. But that doesn't concern Astaro. However, it might be worth mentioning that being on the same subnet as a person's ISP's (quasi hidden) net might not be the best course of action. Or would the ASG handle the same subnet on both sides of a modem just fine?

Jim, I think the only time there might be a problem would be if you had a VPN between the two.  You have masquerading that hides your internal IPs, and no route to get out to theirs.  You're OK unless there's a glitch like you seem to have discovered, or an error like using the HTTP Proxy in full-transparent mode.  Or, have I missed a consideration?

Cheers - Bob

My take on it is that the LAN net should be translated by NAT. If it's not there is something wrong.

Expections that I know about are:

1) VPN
2) HTTPS/SSL
3) A script (malicious or not) that causes one's browser to initiate a direct connection. An example would be:

Anonymous Surfing

Which according to them is a cross-site script that uses iframe. I did confirm something like that by capturing the packets. My browser sent "GET /audit.asp?a=192.168.LAN.IP HTTP/1.1" to their server at 198.104.150.202. NAT did function as the scr IP was my WAN IP. Looks like it used a session cookie too. 


4) Having port 137 open or forwarded.
5) A VNC connection to a remote PC.
6) A Cookie

I'm sure that there are others of which I cannot immediately think.

However, I do not believe that a "hey I'm done playing" - [ACK FIN] or [ACK RST] packet should be in the list. Specificly, I believe NAT should handle the packets in question.

Am I wrong?



Jim

Well, I think I'll add your last post to my "stuff I can use that I haven't yet understood."  I think you know a lot more about a lot of this than I do!

Do you think it's worth changing our 10. local networks where Cox is the ISP to 172. so they cannot possibly collide with Cox?

Cheers - Bob

Oh, just a reminder...

Without a catch all any/any/any at the bottom of the packet filter list with logging turned off, I get a lot of default dropped packets from outbound [ACK FIN] and [ACK RST] packets sent to my logging box. Which interferes with my ability to see the important dropped packets. It also fills the "Top Dropped Source Hosts" db in the ASG with stuff that should not be considered in the "Top Ten". 

That on top of the already useless data created by messenger spammers on ports 1026 and 1027, the scanners using source ports 6000 and 12200, and the up2date server traffic dropped from port 2080, the ASG top ten list becomes almost unusable.

Of course I guess I could choose not log or display outbound traffic...



Jim

I still have not heard if anyone else has observed this behavior...

Alan?