Re: [squid-users] invalid request problem with wireshark capturing

On 15.03.2012 08:03, Mustafa Raji wrote:
> hi
> still the problem of invalid request problem exist in my caches
> server, i will explain this problem with more deletes here hopping
> there is some thing i don't know about in squid solve this problem
>
> as a trying i did capturing to the invalid request and the captured
> packet deletes is
>
> Frame 4139: 110 bytes on wire (880 bits), 110 bytes captured (880
> bits)
> Arrival Time: Mar 13, 2012 11:53:02.536140000 AST
> Epoch Time: 1331628782.536140000 seconds
> Time delta from previous captured frame: 0.008177000 seconds
> Time delta from previous displayed frame: 0.008177000 seconds
> Time since reference or first frame: 51.377354000 seconds
> Frame Number: 4139
> Frame Length: 110 bytes (880 bits)
> Capture Length: 110 bytes (880 bits)
> Frame is marked: False
> Frame is ignored: False
> Protocols in frame: eth:ip:tcp:http:data
> Coloring Rule Name: HTTP
> Coloring Rule String: http || tcp.port == 80
>
> Internet Protocol, Src: 192.168.40.3 (192.168.40.3), Dst:
> 10.10.10(10.10.10.53)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 96
> Identification: 0x23e0 (9184)
> Flags: 0x02 (Don't Fragment
> Fragment offset: 0
> Time to live : 127
> Protocol : TCP (6)
> Header checksum: 0xdacd [correct]
> source 10.10.10.53 (10.10.10.53
> Destination: 192.168.40.3 (192.168.40.3)
> Transmission Control Protocol, Src Port:49869 (49869), Dst Port: http
> (80), seq:
> Source port: 49869 (49869)
> Destination port: http (80)
> [Stream index: 240]
> Sequence number: 1 (relative squence number)
> [NEXT squence number: 57 (relative sequence number)]
> Acknowledgement number: 1 (relative ack number)
> Header length: 20 bytes
> Flags: 0x18 (PSH, ACK)
> window size: 17520 (scaled)
> Checksum: 0xba28 [validation disabled]
> [SEQ/ACK analysis]
> *Hypertext Transfer Protocol
>   *DATA (56 bytes)
>    Data:0569ff24fdd6dbd18ffe4d2f2fffaa9020alae217a53923a..
>     [Length: 56]
>
> the squid is recognize the ips of the client in the access.log file,
> the policy routing in mikrotik done using the dstnat rule, what ever

You seem to be confusing the two systems.

  "NAT" is NAT or NAPT maybe both, (*address translation*).
  Policy routing is a type of routing (*packet delivery*).

They are not the same. Routing cannot do NAT and NAT cannot do routing.
No more than a postman can change the street your house is on, or the
house you live in can delivery peoples mail.
  NAT is like the postman who changes the erases address on the letters
with his friends address then puts them back in a post box.

Please get that straight. You have managed to get it "working" (sort
of) because of some security vulnerabilities in Squid and HTTP, but it
will break when anything involving those security holes changes ...

> packets comes from any source ip address except the ip of the cache
> server in the tcp port at port 80 is distend to the ip address of the
> cache port 80
> to be a clear it's the same as this linux rule
> this rule is for clearance not applied in the linux iptables (because
> i don't know who to explain to you what i did in mikrotik router)
> iptables -t nat -A PREROUTING -p tcp --dport 80 ! -s 192.168.40.2 -j
> DNAT --to-destination 192.168.40.2:80
> where 192.168.40.2 is the ip of the cache server
>
> if the problem is with sending ssl request to the cache server
> through the 80 port but why this happening this type of traffic
> should
> work on port number 433 so the mikrotik rule does not applied for
> this
> type of traffic

What do you mean? You have found some software abusing port 80 to try
and sneak things past your firewall security system? Squid breaking such
abusive things is *good*.

NOTE:
  - traffic *MUST NOT* be sent by browsers etc to the proxy on port 80.
There is port 3128 for proxy traffic (maybe others >1024 if you want).

  - SSL+HTTP native traffic *MUST NOT* be sent on port 80 either. It
goes on port 443.

  - SSL traffic (any kind) *MAY* be sent to the proxy on port 3128 so
long as it is wrapped in a special plain-HTTP CONNECT request.

So what is the problem?

Amos
Received on Wed Mar 14 2012 - 22:49:40 MDT