Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 37 replies
  • Subscribers 2 subscribers
  • Views 35485 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NAT malfunction LAN on WAN

Jim Tagert
While examining the logs, I noticed a pattern that was quite disturbing; my LAN addresses are being sent to the internet. All packets appear to be ACK FIN. RST ACk packets have also been captured.

Inclosed is a packet capture between the ASG and my modem (which I own).

Can someone please explain this?



Jim


This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to BAlfson
    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?
Children
  • 0 in reply to Jim Tagert
    Strange that a PF rule would help, as Astaro has a default logdrop PF rule.

    Barry
  • 0 in reply to BarryG
    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
  • 0 in reply to Jim Tagert
    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
  • 0 in reply to BarryG
    ...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.
  • 0 in reply to Jim Tagert
    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?
  • 0 in reply to dilandau
    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
  • 0 in reply to Jim Tagert
    I don't use the proxy, fwiw.

    Barry
  • 0 in reply to BarryG
    Barry, you don't use the HTTP proxy?
  • 0 in reply to BarryG
    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
  • 0 in reply to Jim Tagert
    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