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.

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?

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.

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?

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

I'm still not sure how the ASG or any FW handles the same subnet on both sides of the modem. 

This may be seen to some as excessive and paranoid. I guess it depends on the person. I currently believe that being on the same subnet as the ISP could make it easier for unwanted problems.

If anyone knows that my thinking is wrong on this, please correct me.

Bob, can you see the address of the CMTS that COX uses on your node? You may also see other activity on the 10/8 subnet. I log ms-sql packets (port 1433 and 1434) fairly regularly originating from within a 10/8 net. Along with other activity from other addresses in the 10/8 net. I do not know if this is normal or a hardware failure in the works.

RR's 10/8 traffic is the reason that I own my moden as well. Any traffic inside my network I can monitor with out appearing to be intruding upon RR's net. Since I own the modem, the dividing line between their network and mine is the coax connection to my modem's wan interface. And since the cable is spliced and I own it as well I could also sniff the outside of my modem if I so choose.

I took my network off of the 10/8 net because I was not 100% sure if a FW could be fooled, confused, or made into an unwilling bridge.

I cannot tell you if it is worth it to change your internal net. For me it was easy since I have a small home network. For me it was worth it to remove doubt. I just do not understand everything. I have not yet set up an experiment to see if I can fool NAT or a router by having the same subnet on both sides of the WAN interface. I can't afford a CMTS yet...


Jim