[j-nsp] "ping: sendto: Operation not permitted" in LAN

[Martin T]

Stefan, Stacy:

thank you for explanations! I made a following setup for testing this:

http://img853.imageshack.us/img853/3366/88435449.png

..and as you can see, I enabled "protocol tcp" under "established"
term and now the results are following:

root> ping 192.168.1.1 source 192.168.1.14 count 10
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss

root>

In other words we get the expected behaviour :)



"The bit positions that would be the ACK or RST TCP flags on a TCP
packet are in the data portion of an ICMP echo request packet."
Yes, those should be 108th and 110th bit in the TCP header
accordingly, which will end up in data portion of ICMP "echo request"
packet because ICMP header is smaller. Probably same applies for
example UDP as well..


"If you also want to permit ICMP echo request messages, add an
additional term to do so."
The main goal I have here is to allow all the traffic from
10.10.10.0/24 network to access network 192.168.1.0/28 without any
restrictions. I always thought that if I try to access
networks(192.168.1.0/28 in this case) directly from the router(using
the 192.168.1.14/32 source IP in this case), the firewall filter is
not applied...I guess I was wrong?


regards,
martin


2011/8/20 Stefan Fouant <sfouant at shortestpathfirst.net>:
> Hi Saku,
>
> I think we are simply getting the wires crossed.  Your original email stated "Trio appears to change this, in inet6 simply doing 'match port X' without 'match next-header tcp|udp' correctly finds port X, regardless of its position in the frame (you can move the UDP/TCP port position via extension headers)."  We were originally talking about TCP options, and somehow the topic got switched to the behavior with ports. I was responding that for port, current incarnations do the same thing (vs. Trio).
>
> I see your point however with regards to other behavior in Trio and agree it's better.
>
> Thanks,
>
> Stefan Fouant
> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
> Technical Trainer, Juniper Networks
> http://www.shortestpathfirst.net
> http://www.twitter.com/sfouant
>
> Sent from my iPad
>
> On Aug 19, 2011, at 4:29 AM, Saku Ytti <saku at ytti.fi> wrote:
>
>> On (2011-08-18 21:23 -0400), Stefan Fouant wrote:
>>
>>> Trio has nothing to do with this - the behavior when matching on a
>>> port is completely different than using the bit-field match
>>> operators.  Even without Trio, if you specify a match on a port
>>> without protocol, it will look in the appropriate locations
>>> depending on whether the traffic is TCP or UDP.  That is not the
>>> case with bit-field match operators.
>>>
>>> See http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-firewall-filter-how-to-specify-match-conditions.html#jd0e29000
>>
>> Thanks for clearing that up. However if 'port' assumes implied udp/tcp (instead
>> of just finding port values in predefined offset, regardless of protocol) why
>> doesn't 'tcp-established' assume implied tcp? Is there any useful application
>> behind this inconsistency?
>>
>> Also do you have access internally to information which you are able to share,
>> when would JunOS CLI get 'match protocol udp|tcp|icmp' for ipv6? So users
>> could, in existance of extension headers still match for L4 protocol?
>>
>> Thanks again,
>> --
>>  ++ytti
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>