On 9/10/2015 1:19 AM, Vieri Di Paola wrote: > >>>> From: Tom Eastep <[email protected]> >>>> >>>> >>>> You can nevertheless do what you want by adding a provider for interface >>>> enp4s1. Make it the 'primary' provider (if your version of Shorewall >>>> doesn't support the 'primary' option, use 'balance'). Then use the >>>> mangle rules that I suggested to balance traffic to the private network. >>> >>> >>> >>> I've added the "internet" primary provider as suggested: >>> >>> WAN 1 1 - $IF_WAN $ADDR_GW_WAN >>> loose,track,primary >>> CAIB 2 2 - $IF_CAIB $ADDR_GW_CAIB loose,track >>> IBS 3 3 - $IF_IBS $ADDR_GW_IBS loose,track >>> >>> Note: I'm supposing CAIB and IBS do not require "fallback" or "balance". I >>> also tried adding "fallback" to both and saw how $ADDR_GW_CAIB and >>> $ADDR_GW_IBS were added to "table default" but it did not change the >>> outcome of my test (see below). >>> >>> I then defined NOTHING in "routes" and "rtrules" and as you >>> suggested I only set up marking in "mangle": >>> >>> MARK(2):P 10.215.144.0/22 10.215.224.0/20 all >>> MARK(2):P 10.215.248.0/24 10.215.224.0/20 all >>> MARK(3):P 10.215.247.194 10.215.236.221 all >>> >>> Traffic to WAN seems to work but connections to CAIB or IBS fail >>> (10.215.224.0/20). >>> >>> eg. ping from 10.215.144.48 ("lan" zone) to 10.215.237.237 ("caib" >>> zone) fails and a traceroute shows that it reaches the shorewall >>> firewall but is not routed out the CAIB provider. >>> >>> I'm attaching the shorewall dump. >>> >>> According to it, the default gateway to internet is in "table >>> balance" and not in "main" anymore (good). Also, according to the routing >>> rules >>> and "mangle", packets sent from 10.215.144.48 to 10.215.237.237 should >>> be marked "2" and should route out via "10001: from all fwmark 0x2/0xff >>> lookup CAIB" (right?). However, traceroute from 10.215.144.48 does not >>> indicate access to $ADDR_GW_CAIB. >>> >>> What's wrong or what am I missing? >> >> Please try a 'shorewall iptrace' of the failing traffic. > > > > I'm sorry but I previously posted a log entry with MARK=2 from an IP address > that WASN'T in the mangle file. > I corrected that by trying a ping from 10.215.144.48 to 10.215.237.237. > The mangle file being (last line is unnecessary, I know): > > MARK(2):P 10.215.144.0/22 10.215.224.0/20 all > MARK(2):P 10.215.248.0/24 10.215.224.0/20 all > MARK(3):P 10.215.247.194 10.215.236.221 all > MARK(2):P 10.215.144.48 10.215.237.237 all > > > After the failed test I get: > > # shorewall dump | grep "10.215.144.48" | grep "10.215.237.237" > 0 0 ~log0 all -- * * 10.215.144.48 > 10.215.237.237 [goto] > 3 180 MARK all -- * * 10.215.144.48 > 10.215.237.237 MARK set 0x2 > > icmp 1 26 src=10.215.144.48 dst=10.215.237.237 type=8 code=0 id=1 > packets=3 bytes=180 [UNREPLIED] src=10.215.237.237 dst=10.215.144.48 type=0 > code=0 id=1 packets=0 bytes=0 mark=0 use=1 > > > I'm expecting mark to be 2, not 0.
You are looking at the *connection* -- it doesn't get marked until a packet *from* the provider and belonging to the connection is received. > > Also, if mark is 0 then wouldn't the packet go out the default > gateway which in my case would be $ADDR_GW_WAN which is out NIC enp4s1? This > default route is in table balance so I guess packets with mark=0 should > get there. If so, then would I be able to tcpdump these packets by > listening on enp4s1? > > The following produces no output while performing ping (the only > interface where I see activity is the "lan" interface of course): > # tcpdump -n -i enp4s1 src 10.215.144.48 and dst 10.215.237.237 > > I'm confused as to why mark is 0 for > src=10.215.144.48/dst=10.215.237.237. See above. > > I'm also assuming I launched the right iptrace command: # shorewall > iptrace --destination 10.215.237.237 but as you can see from the > grep'ed shorewall dump above there's no log entry for 10.215.144.48 . > I even added > > ACCEPT:info(ip_options,tcp_sequence,tcp_options) > lan:10.215.144.48 caib:10.215.237.237 all > before any other lan2caib rules. > > I also checked /proc/kmsg. > > What else can I try? > We still need the iptrace output. That output is directed according to the current setting of LOG_BACKEND. If you want the output to be handled by syslog-ng, use LOG_BACKEND=LOG. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
