Hi,
After having alot of trouble with my 2 ISP setup, ive stipped it down to
make it as simple as possible. I still have a tiny glitch and I would like
to have your inputs on this. Here it is:
-=SETUP=-
Shorewall 3.0.3 on FC4
Two providers:
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY
OPTIONS COPY
ispuvwxyz 1 1 main ppp0 detect
balance,track eth0
ispabcdef 2 2 main eth2 detect
balance,track eth0
Two simple rules for testing purposes:
#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST
PORT(S)
2 $FW 0.0.0.0/0 tcp 666
1 $FW 0.0.0.0/0 tcp 178
-=The problem=-
When I test both TCP ports as destination (using TELNET <ip> <port>
from FW)
both connections
are forwarded to ETH2(isp2). TCP 178 is never sent to ISP1.
I captured this test (to packets sent with each tcp ports) in my shorewall
dump, see attachement.
(All configurations files are also included in the attachement)
Marking seems to work perfectly from what I see in the dump. (2 packets,
two marks)
Masquerading also seems to do its work.
NOTE: Before this simple setup, I used marking on my lan interface (eth0)
and everything worked fine. Only traffic originating from $FW is causing
trouble.
Thanks alot everyone.
Thanks to Tom and Jerry for putting me on the right track in the first
place.
SiO
On Tuesday 03 January 2006 01:45, Child from KoRn wrote:> > When I test both TCP ports as destination (using TELNET <ip> <port> from > FW) both connections > are forwarded to ETH2(isp2). TCP 178 is never sent to ISP1.Are you using the same remote IP address for both ports? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Child from KoRn wrote:> Hi, > > After having alot of trouble with my 2 ISP setup, ive stipped it down to > make it as simple as possible. I still have a tiny glitch and I would > like to have your inputs on this. Here it is: > > -=SETUP=- > > Shorewall 3.0.3 on FC4 > > Two providers: > > #NAME NUMBER MARK DUPLICATE INTERFACE > GATEWAY OPTIONS COPY > ispuvwxyz 1 1 main ppp0 > detect balance,track eth0 > ispabcdef 2 2 main eth2 > detect balance,track eth0 > > Two simple rules for testing purposes: > > #MARK SOURCE DEST PROTO PORT(S) CLIENT USER > TEST PORT(S) > 2 $FW 0.0.0.0/0 tcp 666 > 1 $FW 0.0.0.0/0 tcp 178 > > > -=The problem=- > > When I test both TCP ports as destination (using TELNET <ip> <port> from > FW) both connections > are forwarded to ETH2(isp2). TCP 178 is never sent to ISP1. >Jan 3 03:48:50 abrams Shorewall:all2vid:DROP:IN= OUT=eth2 SRC=28.200.89.15 DST=111.222.111.222 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=15842 DF PROTO=TCP SPT=56825 DPT=178 WINDOW=5840 RES=0x00 SYN URGP=0 ^^^^^^^ Chain ppp0_masq (1 references) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * * 10.10.10.7 0.0.0.0/0 to:69.68.91.170 ^^^^^^^^ you have: ppp0 $ETH0_IP $PPP0_IP S/B: ppp0 $ETH2_IP $PPP0_IP Eth2 is your providers interface Jerry ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Hi,>Are you using the same remote IP address for both ports? >-TomIn this current dump example, yes. It simulates me accessing 2 services on the same remote host. For example a FTP server and WEB server on the same remote host. I did try using different destination but I had the same problem. Ill go and capture the same test but with different IP''s.>you have: >ppp0 $ETH0_IP $PPP0_IP > >S/B: >ppp0 $ETH2_IP $PPP0_IP > >Eth2 is your providers interface >Your right Jerry. So right. Ill go fix this and try it right now. BRB. Thx!> >Child from KoRn wrote: >>Hi, >> >>After having alot of trouble with my 2 ISP setup, ive stipped it down to >>make it as simple as possible. I still have a tiny glitch and I would >>like to have your inputs on this. Here it is: >> >>-=SETUP=- >> >>Shorewall 3.0.3 on FC4 >> >>Two providers: >> >>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY >> OPTIONS COPY >>ispuvwxyz 1 1 main ppp0 detect >> balance,track eth0 >>ispabcdef 2 2 main eth2 detect >> balance,track eth0 >> >>Two simple rules for testing purposes: >> >>#MARK SOURCE DEST PROTO PORT(S) CLIENT USER >>TEST PORT(S) >>2 $FW 0.0.0.0/0 tcp 666 >>1 $FW 0.0.0.0/0 tcp 178 >> >> >>-=The problem=- >> >>When I test both TCP ports as destination (using TELNET <ip> <port> from >>FW) both connections >>are forwarded to ETH2(isp2). TCP 178 is never sent to ISP1. >> >Jan 3 03:48:50 abrams Shorewall:all2vid:DROP:IN= OUT=eth2 SRC=28.200.89.15 >DST=111.222.111.222 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=15842 DF PROTO=TCP >SPT=56825 DPT=178 WINDOW=5840 RES=0x00 SYN URGP=0 > ^^^^^^^ > >Chain ppp0_masq (1 references) > pkts bytes target prot opt in out source >destination > 0 0 SNAT all -- * * 10.10.10.7 0.0.0.0/0 > to:69.68.91.170 ^^^^^^^^ > >you have: >ppp0 $ETH0_IP $PPP0_IP > >S/B: >ppp0 $ETH2_IP $PPP0_IP > >Eth2 is your providers interface > >Jerry > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log >files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Shorewall-users mailing list >Shorewall-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Hi,>Ill go fix this and try it right now.I did correct the MASQ error I had. Now the rule is good: Chain ppp0_masq (1 references) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * * 28.200.89.15 0.0.0.0/0 to:69.156.128.98 But I still have the same problem, FW originating traffic aint fowarded according to my tcrules file. Everything else is working fine. Tell me if im wrong, but aint the MASQ the last step before the paquet leaves my ISP''s interface? My problem seems to occurs before this step. Once the paquet reaches my ISP2''s interface, its already to late because the paket is already at the wrong place and should have been "policy forwarded" to ISP1''s interface in the first place. What do you think? Ive manage to get a great example of my "shorewall dump" again. This time I captured 2 paquets, different DST IPs. 1) DST=111.2.111.2 TCP 666 Jan 3 16:37:24 MyComp Shorewall:fw2vid:ACCEPT:IN= OUT=eth2 SRC=24.200.89.15 DST=111.2.111.2 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=46595 DF PROTO=TCP SPT=39195 DPT=666 WINDOW=5840 RES=0x00 SYN URGP=0 2) DST=111.9.111.9 TCP 178 Jan 3 16:37:34 MyComp Shorewall:all2vid:DROP:IN= OUT=eth2 SRC=24.200.89.15 DST=111.9.111.9 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=4746 DF PROTO=TCP SPT=46747 DPT=178 WINDOW=5840 RES=0x00 SYN URGP=0 TCP 666 did go to ISP2 (eth2) like indicated in the Tcrules, but TCP 178 did not go to ISP1 (ppp0) like indicated in Tcrules and went out eth2 anyways. BTW I use "Telnet <dst ip> <dst port>" from my FW to test TCP ports. I use TCP DUMP on both ISP interfaces and I also watch my /var/log/messages logs for monitoring. Is there any better way? Thats for your help guys.> >Hi, > >>Are you using the same remote IP address for both ports? >>-Tom > >In this current dump example, yes. >It simulates me accessing 2 services on the same remote host. For example a >FTP server and WEB server on the same remote host. > >I did try using different destination but I had the same problem. >Ill go and capture the same test but with different IP''s. > >>you have: >>ppp0 $ETH0_IP $PPP0_IP >> >>S/B: >>ppp0 $ETH2_IP $PPP0_IP >> >>Eth2 is your providers interface >> > >Your right Jerry. So right. >Ill go fix this and try it right now. > >BRB. > >Thx! > > > > > > > > > > > > > > > > > >> >>Child from KoRn wrote: >>>Hi, >>> >>>After having alot of trouble with my 2 ISP setup, ive stipped it down to >>>make it as simple as possible. I still have a tiny glitch and I would >>>like to have your inputs on this. Here it is: >>> >>>-=SETUP=- >>> >>>Shorewall 3.0.3 on FC4 >>> >>>Two providers: >>> >>>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY >>> OPTIONS COPY >>>ispuvwxyz 1 1 main ppp0 detect >>> balance,track eth0 >>>ispabcdef 2 2 main eth2 detect >>> balance,track eth0 >>> >>>Two simple rules for testing purposes: >>> >>>#MARK SOURCE DEST PROTO PORT(S) CLIENT USER >>>TEST PORT(S) >>>2 $FW 0.0.0.0/0 tcp 666 >>>1 $FW 0.0.0.0/0 tcp 178 >>> >>> >>>-=The problem=- >>> >>>When I test both TCP ports as destination (using TELNET <ip> <port> from >>>FW) both connections >>>are forwarded to ETH2(isp2). TCP 178 is never sent to ISP1. >>> >>Jan 3 03:48:50 abrams Shorewall:all2vid:DROP:IN= OUT=eth2 >>SRC=28.200.89.15 DST=111.222.111.222 LEN=60 TOS=0x10 PREC=0x00 TTL=64 >>ID=15842 DF PROTO=TCP SPT=56825 DPT=178 WINDOW=5840 RES=0x00 SYN URGP=0 >> ^^^^^^^ >> >>Chain ppp0_masq (1 references) >> pkts bytes target prot opt in out source >>destination >> 0 0 SNAT all -- * * 10.10.10.7 0.0.0.0/0 >> to:69.68.91.170 ^^^^^^^^ >> >>you have: >>ppp0 $ETH0_IP $PPP0_IP >> >>S/B: >>ppp0 $ETH2_IP $PPP0_IP >> >>Eth2 is your providers interface >> >>Jerry >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >>_______________________________________________ >>Shorewall-users mailing list >>Shorewall-users@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log >files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Shorewall-users mailing list >Shorewall-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/shorewall-users
On Tuesday 03 January 2006 14:51, Child from KoRn wrote:> Hi, > > >Ill go fix this and try it right now. > > I did correct the MASQ error I had. > Now the rule is good: > > Chain ppp0_masq (1 references) > pkts bytes target prot opt in out source > destination > 0 0 SNAT all -- * * 28.200.89.15 > 0.0.0.0/0 to:69.156.128.98 > > But I still have the same problem, FW originating traffic aint fowarded > according to my tcrules file. Everything else is working fine. > > Tell me if im wrong, but aint the MASQ the last step before the paquet > leaves my ISP''s interface? > My problem seems to occurs before this step. Once the paquet reaches my > ISP2''s interface, its already to late because the paket is already at the > wrong place and should have been "policy forwarded" to ISP1''s interface in > the first place. What do you think? > > Ive manage to get a great example of my "shorewall dump" again. > > This time I captured 2 paquets, different DST IPs. > > > 1) DST=111.2.111.2 TCP 666 > > Jan 3 16:37:24 MyComp Shorewall:fw2vid:ACCEPT:IN= OUT=eth2 > SRC=24.200.89.15 DST=111.2.111.2 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=46595 > DF PROTO=TCP SPT=39195 DPT=666 WINDOW=5840 RES=0x00 SYN URGP=0 > > > 2) DST=111.9.111.9 TCP 178 > > Jan 3 16:37:34 MyComp Shorewall:all2vid:DROP:IN= OUT=eth2 SRC=24.200.89.15 > DST=111.9.111.9 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=4746 DF PROTO=TCP > SPT=46747 DPT=178 WINDOW=5840 RES=0x00 SYN URGP=0 > > TCP 666 did go to ISP2 (eth2) like indicated in the Tcrules, but TCP 178 > did not go to ISP1 (ppp0) like indicated in Tcrules and went out eth2 > anyways. > > BTW I use "Telnet <dst ip> <dst port>" from my FW to test TCP ports. I use > TCP DUMP on both ISP interfaces and I also watch my /var/log/messages logs > for monitoring. Is there any better way? >I believe that your problem is in the setup of your zones and policies. You can see this most clearly if you look at the diagram at the top of http://www1.shorewall.net/Shorewall_and_Routing.html. Other articles relevant to this discussion are: http://www1.shorewall.net/NetfilterOverview.html http://www1.shorewall.net/PacketHandling.html Netfilter''s handling of packets originating on the firewall is inconsistent with its handling of other packets. In the other cases, packets go through the PREROUTING chains before being routed. In those chains, the destination IP address can be rewritten (DNAT), packets can be marked or their TOS class changed. These changes are then available at the time that the routing decision is made and before the packets pass through the FORWARD chains (or the INPUT chains). Packets that originate on the firewall go through different processing. The packet is first provisionally routed. It then goes through the OUTPUT chains where its destination IP address can be rewritten and it can be marked or have its TOS class changed. If any such changes occur, then the packet GOES THROUGH ROUTING AGAIN. The net result of this is that when the packet goes through the OUTPUT chain of the filter table, its output interface MAY BE WRONG. So if filtering based out the output interface is done in the OUTPUT filter chain (which is what you are doing), packets can be DROPPED or REJECTED before they can be rerouted. It was my impression that the rerouting occured before packets traversed the OUTPUT chain of the filter table but you have provided us with pretty conclusive evidence that it does not. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Child from KoRn
2006-Jan-06 05:51 UTC
shorewall refresh command - Sourcing from the init file ???(take 2)
Hi, While I was cleaning up my new shorewall setup, I realized I had a little problem. The "shorewall refresh" command did not work and gave me an error message (see link below). But, the "shorewall restart" command worked fine. After chatting with Jim on IRC, we came to the conclusion that maybe the "shorewall refresh" command did not source from the "init" file (cause my tcfile does contain variables that are defined in init). Could this be possible? Here are the pastebin links: shorewall debug start: http://pastebin.com/492908 shorewall debug refresh: http://pastebin.com/492909 Thx SiO ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Jerry Vonau
2006-Jan-06 07:25 UTC
Re: shorewall refresh command - Sourcing from the init file ???(take 2)
Child from KoRn wrote:> Hi, > > While I was cleaning up my new shorewall setup, I realized I had a > little problem. > The "shorewall refresh" command did not work and gave me an error > message (see link below). > > But, the "shorewall restart" command worked fine. > > After chatting with Jim on IRC, we came to the conclusion that maybe the > "shorewall refresh" command did not source from the "init" file (cause > my tcfile does contain variables that are defined in init). >Great, my ex-boss get the credit, go figure... ;-) # + shift # + ''['' 7 -gt 0 '']'' # + eval ''varval=$sources'' # ++ varval=''$FW:$PPP0_IP'' # + eval ''sources="$FW:$PPP0_IP"'' # ++ sources=fw: # + shift I recall that those commands were placed in the params file in the past, the fastest fix is to move those variables into the params file. Tom, is it OK/safe to do that? On a side note, is your isp''s dhcp server really running on udp 63? + echo ''2:P $FW:$ETH2_IP 0.0.0.0/0 udp 63 #REQUETES DHCP DU SERVEUR (eth2) GOTTA GO TO VIDEOTRON'' Jerry ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Tom Eastep
2006-Jan-06 14:54 UTC
Re: shorewall refresh command - Sourcing from the init file ???(take 2)
On Thursday 05 January 2006 23:25, Jerry Vonau wrote:> > I recall that those commands were placed in the params file in the past, > the fastest fix is to move those variables into the params file. > > Tom, is it OK/safe to do that? >It is the correct way to do that. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Jerry Vonau
2006-Jan-06 17:00 UTC
Re: shorewall refresh command - Sourcing from the init file ???(take 2)
Tom Eastep wrote:> On Thursday 05 January 2006 23:25, Jerry Vonau wrote: > > >>I recall that those commands were placed in the params file in the past, >>the fastest fix is to move those variables into the params file. >> >>Tom, is it OK/safe to do that? >> > > > It is the correct way to do that. >Just checking for everybody''s benefit, as the FAQs use the init file for where to add those commands. Jerry ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Tom Eastep
2006-Jan-06 17:09 UTC
Re: shorewall refresh command - Sourcing from the init file ???(take 2)
On Friday 06 January 2006 09:00, Jerry Vonau wrote:> Just checking for everybody''s benefit, as the FAQs use the init file for > where to add those commands.The FAQ is also referring to a DNAT rule which has nothing to do with refresh. Nevertheless, for the copy-and-paste crowd I''ve the references to /etc/shorewall/init in the FAQ to /etc/shorewall/params. Please see http://www.shorewall.net/configuration_file_basics.html#Variables for the definitive documentation on using shell variables with Shorewall. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Eduardo Ferreira
2006-Jan-06 17:37 UTC
Re: shorewall refresh command - Sourcing from the init file ???(take 2)
Tom Eastep wrote on 06/01/2006 15:09:50:> Please seehttp://www.shorewall.net/configuration_file_basics.html#Variables> for the definitive documentation on using shell variables withShorewall.>in the document: If the firewall''s external interface is the DECchip controllor s/controllor/controller/ -- Eduardo //entering 2006 in the a-r mood...
Tom Eastep
2006-Jan-06 17:49 UTC
Re: shorewall refresh command - Sourcing from the init file ???(take 2)
On Friday 06 January 2006 09:37, Eduardo Ferreira wrote:> > If the firewall''s external interface is the DECchip controllor > > s/controllor/controller/ >Corrected -- thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key