Re: [Fwbuilder-discussion] can't allow return TCP or ICMP traffic

[<va...@vk...>]

On Dec 12, 2006, at 9:27 AM, Mike Williams wrote:

> On Tuesday 12 December 2006 16:00, Vadim Kurland =E2=9C=8D wrote:
>> You are right, ping reply should match rule matching
>> ESTABLISHED,RELATED states that is added on top of the policy.
>>
>> however the packet actually came in through the VPN. I am not an
>> expert on VPNs and you have not mentioned the kind of VPN you use,
>> but I think you should look at how it is set up and what rules you
>> have for it. I know for some kinds of IPSEC people have to mark
>> packets entering the firewall and then use the mark to permit/deny
>> them after they get decapsulated. Fwbuilder 2.1 allows you to do such
>> marking using rule action Tag and then you can match tags using new
>> service 'tag'.
>
> It's OpenSwan both ends, and packets go in and out as any other =20
> packets.
> On all the other firewalls I just allow and deny based on IP =20
> ranges. One of
> them is now on a script generated by 2.1, and showing no odd =20
> behaviour.
>
> I now have a rule 34 which, in fwbuilder, is source 192.168.0.0/16,
> destination any, service any, interface br0, inbound, accept. But =20
> the packets
> skip by it. If I edit the script by hand, to remove the "-m state --=20=

> state
> NEW" bit, and apply it, the packets get accepted.
>

you can make fwbuilder generate this command without "-m state --=20
state NEW" by checking a checkbox to make this one rule stateless in =20
the rule options dialog.


> I've just tried the tag thing, but as I can't make a rule that =20
> matches this
> traffic, I can't tag it to accept it.
>

it would have to match IPSEC I guess. There are many examples on =20
various sites on the Internet of how to deal with IPSEC tunnels with =20
iptables.


> Seems like the packets are neither ESTABLISHED, or RELATED, and not =20=

> NEW
> either ... They are however INVALID ! If I change the script by =20
> hand to match
> on INVALID states it works.
> Hopefully this is being caused by my overly complex, slightly =20
> broken, upstream
> network.
>
> thefirewall # ping www.google.co.uk
> PING www.l.google.com (209.85.135.147) 56(84) bytes of data.
> =46rom 69.91.155.183.in-addr.arpa (183.155.91.69): icmp_seq=3D1 =20
> Redirect Host(New
> nexthop: 49.167.187.22.in-addr.arpa (22.187.167.49))
> 64 bytes from 209.85.135.147: icmp_seq=3D1 ttl=3D242 time=3D53.9 ms
> =46rom 69.91.155.183.in-addr.arpa (183.155.91.69): icmp_seq=3D4 =20
> Redirect Host(New
> nexthop: 49.167.187.22.in-addr.arpa (22.187.167.49))
> 64 bytes from 209.85.135.147: icmp_seq=3D4 ttl=3D241 time=3D32.5 ms
> =46rom 69.91.155.183.in-addr.arpa (183.155.91.69): icmp_seq=3D10 =20
> Redirect Host(New
> nexthop: 49.167.187.22.in-addr.arpa (22.187.167.49))
> 64 bytes from 209.85.135.147: icmp_seq=3D10 ttl=3D242 time=3D45.8 ms
>

so this is ICMP redirect. This does not necessarily mean network is =20
broken. It just means 22.187.167.49 is "better" gateway than =20
183.155.91.69 This does not make sense though since these addresses =20
are on completely different networks. ICMP redirect is sent by a =20
gateway when it determines that it needs to forward a packet to =20
another gateway on the same subnet (because the originator could have =20=

used that another gateway in the first place and avoided extra hop)

I am not sure what bearing does this have on your IPSEC problem.

> 22.187.167.49 is the "LAN" side of a DSL router, 183.155.91.69 is a =20=

> bridge
> interface of a machine on said "LAN" side and part of a second =20
> range assigned
> to us by our ISP. The bridge has an IP on the "LAN" range, which =20
> the router
> routes the new range too (it doesn't support more than one range on
> the "LAN"). The bridge has a specific route for traffic from the =20
> new range,
> to the "LAN" side IP of the router.
> My public IPs are munged.