Re: [Shorewall-users] routing issue with rtrules (with SW dump)

[Simon M. <sim...@in...>]

>
> ________________________________
> From: Simon Matter <sim...@in...>
>
>>> This is the failing ping performed on $FW:
>>>
>>> # ping -I 10.215.246.91 10.215.236.123 -c 1
>>
>> Last week you asked the list about a possible arp cache issue. Did you
>> find a solution there or is the issue you report now probably related?
>>
>> Since you didn't let us know what came out last week I'm not sure both
>
>> things are related or not.
>
> Hi Simon,
>
> I didn't follow up on my last issue regarding arp cache because I ran into
> several critical issues. I noticed that my main switch had a default cache
> timeout of 300 seconds. I lowered it to 1s before doing the FW change, and
> set it back to 300s afterwards. This helped because the change was very
> fast, and the clients connected to the first layer of switches were
> quickly working again. However, some other clients had trouble, and had to
> be rebooted.
> In any case, traffic was apparently flowing as expected in all zones
> except for one (the WAN zone, or internet access). Since I wasn't able to
> pinpoint the cause of the problem in due time, I had to revert to the old
> FW. I wasn't even able to do a correct "shorewall dump" as specified in
> the troubleshooting guide since I confused "shorewall reset" with
> "shorewall clear". :-(
>
>
> The ping issue I reported here was occurring after falling back to the old
> FW. I mean *really* after -- at least three hours later.
> Since this wasn't critical I ignored it until I tested it again this
> morning.
> This time it worked as expected.
>
> Do you know how I can relate this to ARP (this is the old FW, and it's
> trying to ping using one of its own IP addresses on the LAN NIC to a
> remote host's IP address through another NIC)? Also, how can I deal with
> this if it ever occurs again? Should I run "arp -d *" on $FW? Or is the
> issue within the ARP cache of the swithes beyond my "other NIC" which are
> remotely administered, and to which I do not have access (except maybe if
> I unplug them).

I can't help you much here I guess. The only thing I have in mind is that
I had to handle ARP issues on a FW where we had a cold standby FW. When
changing the FW some hosts didn't work until I added the following to the
"init" script then:

grep -s -v "^ *#" /etc/shorewall/proxyarp | while read address interface
external haveroute; do
  ip addr add $address dev $external
  arping -q -A -c 1 -I $external $address
  ( sleep 2 ; arping -q -U -c 1 -I $external $address ; ip addr del
$address dev $external ) > /dev/null 2>&1 < /dev/null &
done
sleep 3

That's more than a decade ago so I don't really remember well.

I'm afraid I can't help you with your other questions.

Simon

>
> This leads me to another question. You previously mentioned that proxyarp
> in Linux can lead to similar issues. I was/am using proxyarp=1 in
> shorewall (old FW) with this in my interfaces file:
>
> lan     $IF_LAN         routeback,proxyarp=1,arp_filter=1
> wan     $IF_WAN         routeback,proxyarp=1,arp_filter=1
> caib    $IF_CAIB        arp_filter=1
> ibs     $IF_IBS         arp_filter=1
> dmz     $IF_DMZ         routeback,dhcp,proxyarp=1
> -       lo              -
>
>
> BTW on the other end of $IF_WAN there's another Shorewall server acting as
> a gateway/router/firewall.
> This is its interfaces file:
>
> net4    $IF_ISP4
> optional,tcpflags,nosmurfs,routefilter=0,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0
> net3    $IF_ISP3
> optional,tcpflags,nosmurfs,routefilter=0,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0
> net2    $IF_ISP2
> optional,tcpflags,nosmurfs,routefilter,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0
> net1    $IF_ISP1
> optional,tcpflags,nosmurfs,routefilter,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0
> dmz     $IF_DMZ         routeback
> loc     $IF_LAN         routeback
>
>
> I used proxyarp on the FW because I had a particular use case a while
> back, but I should not require it anymore. I was hoping to use this
> interfaces file instead:
>
> lan $IF_LAN routeback,arp_filter=1
> wan $IF_WAN routeback,arp_filter=1
> caib $IF_CAIB arp_filter=1
> ibs $IF_IBS arp_filter=1
> dmz $IF_DMZ routeback,dhcp
> - lo -
>
>
> However, when I replaced the old FW with the new one without "proxyarp=1"
> connections were not working within my zones. When I re-enabled
> "proxyarp=1" all zone traffic worked except for LAN2WAN.
> Anyway, I'll post a dump later on if I get the chance. In the meantime,
> I'd like to know how to truly disable proxyarp on a system that had it
> enabled previously. Removing "proxyarp=1" might not be enough. I might
> need to use "proxyarp=0"? Or should I echo 0 >
> /proc/sys/net/ipv4/conf/DEVICE/proxy_arp?
> I'm asking because even after removing "proxyarp=1" I still have this in
> the system:
>
> # cat /proc/sys/net/ipv4/conf/$IF_LAN/proxy_arp
> 1
> # cat /proc/sys/net/ipv4/conf/$IF_WAN/proxy_arp
> 1
> # cat /proc/sys/net/ipv4/conf/$IF_DMZ/proxy_arp
> 1
>
> Thanks,
>
> Vieri
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Shorewall-users mailing list
> Sho...@li...
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>