Hi All, I have, as you all know, a multi-isp setup on an openwrt platform. Things have been going tickity-boo since I tweaked the up/down scripts of my Internet interface address acquisition protocols (DHCP and PPPoE) to include much of the shorewall code bits that build the routing tables and so forth. This morning though I have run into a situation that seems to defy my routing set up. I have the firewall set to accept ssh on port 2222 and while connections through my "CGCO" interface seem to work, connections through my "IGS" interface don''t. The initial SYN is received on the IGS interface just fine but for some reason the SYN-ACK wants to leave on the CGCO interface. For reference CGCO==vlan2 and IGS=ppp0: Here''s the incoming connection requests: root@wireless:~# tcpdump -i ppp0 -n port 2222 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 08:24:07.714235 IP 206.168.112.79.59910 > 66.11.173.224.2222: S 3788444964:3788444964(0) win 5840 <mss 1400,sackOK,timestamp 43994603 0,nop,wscale 7> 08:24:13.217385 IP 206.168.112.79.59919 > 66.11.173.224.2222: S 3896916709:3896916709(0) win 5840 <mss 1400,sackOK,timestamp 43995978 0,nop,wscale 7> And here are the responses: root@wireless:~# tcpdump -i vlan2 -n port 2222 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 96 bytes 08:24:07.714906 IP 66.11.173.224.2222 > 206.168.112.79.59910: S 2094352526:2094352526(0) ack 3788444965 win 5648 <mss 1412,nop,nop,sackOK,nop,wscale 0> 08:24:09.504902 IP 66.11.173.224.2222 > 206.168.112.79.59910: S 2094352526:2094352526(0) ack 3788444965 win 5648 <mss 1412,nop,nop,sackOK,nop,wscale 0> 08:24:13.218516 IP 66.11.173.224.2222 > 206.168.112.79.59919: S 2209377383:2209377383(0) ack 3896916710 win 5648 <mss 1412,nop,nop,sackOK,nop,wscale 0> 08:24:16.304501 IP 66.11.173.224.2222 > 206.168.112.79.59919: S 2209377383:2209377383(0) ack 3896916710 win 5648 <mss 1412,nop,nop,sackOK,nop,wscale 0> 08:24:22.304200 IP 66.11.173.224.2222 > 206.168.112.79.59919: S 2209377383:2209377383(0) ack 3896916710 win 5648 <mss 1412,nop,nop,sackOK,nop,wscale 0> 08:24:34.303584 IP 66.11.173.224.2222 > 206.168.112.79.59919: S 2209377383:2209377383(0) ack 3896916710 win 5648 <mss 1412,nop,nop,sackOK,nop,wscale 0> 08:24:58.502369 IP 66.11.173.224.2222 > 206.168.112.79.59919: S 2209377383:2209377383(0) ack 3896916710 win 5648 <mss 1412,nop,nop,sackOK,nop,wscale 0> My routing configuration: root@wireless:~# ip rule ls 0: from all lookup local 10064: from all fwmark 0x40 lookup CGCO 10128: from all fwmark 0x80 lookup IGS 20000: from 72.38.139.100 lookup CGCO 20256: from 66.11.173.224 lookup IGS 32766: from all lookup main 32767: from all lookup default root@wireless:~# ip route ls table IGS 10.33.66.2 dev tun0 proto kernel scope link src 10.33.66.1 192.168.200.1 dev ppp0 scope link src 66.11.173.224 10.75.22.0/24 dev br0 proto kernel scope link src 10.75.22.199 10.75.23.0/24 via 10.33.66.2 dev tun0 72.38.136.0/21 dev vlan2 proto kernel scope link src 72.38.139.100 default via 192.168.200.1 dev ppp0 The connection mark appears to be correct as well: root@wireless:~# grep 2222 /proc/net/ip_conntrack tcp 6 49 SYN_RECV src=206.168.112.79 dst=66.11.173.224 sport=59910 dport=2222 src=66.11.173.224 dst=206.168.112.79 sport=2222 dport=59910 use=1 mark=128 bytes=932 tcp 6 56 SYN_RECV src=206.168.112.79 dst=66.11.173.224 sport=59919 dport=2222 src=66.11.173.224 dst=206.168.112.79 sport=2222 dport=59919 use=1 mark=128 bytes=164 So I am kind of puzzled why these SYN-ACKs are not being routed out via the correct interface. Upon looking, I also wonder if the "from <address>" ip rules should be higher in the table than the "from all fwmark" rules. The source address should absolutely decide which interface to route out of regardless of fwmark, no? Any ideas? b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> > Any ideas? >"shorewall dump" output, please. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Tom Eastep wrote:> Brian J. Murrell wrote: > >> Any ideas? >> > > "shorewall dump" output, please.Also, is sshd listening on address 66.11.173.224:2222 or is it listening on 0:2222? -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, 2007-05-09 at 07:51 -0700, Tom Eastep wrote:> > Also, is sshd listening on address 66.11.173.224:2222 or is it listening on > 0:2222?*:2222: root@wireless:~# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:2222 *:* LISTEN b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, 2007-05-09 at 07:23 -0700, Tom Eastep wrote:> Brian J. Murrell wrote: > > > > > Any ideas? > > > > "shorewall dump" output, please.[ sent ] But I was looking (with tcpdump) at what was leaving the ppp0 interface and noticed that there are packets with a source address of the vlan2 interface leaving, which is wrong. So to the nat table I go and see this: Chain POSTROUTING (policy ACCEPT 1862 packets, 195K bytes) pkts bytes target prot opt in out source destination 0 0 ppp0_masq all -- * ppp0 0.0.0.0/0 0.0.0.0/0 10773 912K vlan2_masq all -- * vlan2 0.0.0.0/0 0.0.0.0/0 It seems that no packets are matching that "out: ppp0" rule, although I can most definitely see packets leaving that interface with tcpdump. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> On Wed, 2007-05-09 at 07:23 -0700, Tom Eastep wrote: >> Brian J. Murrell wrote: >> >>> Any ideas? >>> >> "shorewall dump" output, please. > > [ sent ] > > But I was looking (with tcpdump) at what was leaving the ppp0 interface > and noticed that there are packets with a source address of the vlan2 > interface leaving, which is wrong. So to the nat table I go and see > this: > > Chain POSTROUTING (policy ACCEPT 1862 packets, 195K bytes) > pkts bytes target prot opt in out source destination > 0 0 ppp0_masq all -- * ppp0 0.0.0.0/0 0.0.0.0/0 > 10773 912K vlan2_masq all -- * vlan2 0.0.0.0/0 0.0.0.0/0 > > It seems that no packets are matching that "out: ppp0" rule, although I > can most definitely see packets leaving that interface with tcpdump.Only packets in the NEW state traverse the nat table. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, 2007-05-09 at 16:05 -0700, Tom Eastep wrote:> > Only packets in the NEW stateWhich is only the first few packets which establish a connection, yes?> traverse the nat table.I must be missing something then. All packets leaving the gateway need to be NATted, not just the ones that create the ESTABLISHED state, right? b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> On Wed, 2007-05-09 at 16:05 -0700, Tom Eastep wrote: >> Only packets in the NEW state > > Which is only the first few packets which establish a connection, yes? > >> traverse the nat table. > > I must be missing something then. All packets leaving the gateway need > to be NATted, not just the ones that create the ESTABLISHED state, > right?Once the conntrack table entry is built, there is no further need of the nat table rules. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, 2007-05-09 at 16:15 -0700, Tom Eastep wrote:> > Once the conntrack table entry is built, there is no further need of the > nat table rules.Ahhh. So you are saying that conntrack then does the natting necessary? So if I add a new rule such as: root@wireless:~# iptables -t mangle -I tcpre -p udp --dport 4569 -j MARK --set-mark 0x80 So that it gets SNATted with the right source address with: Chain ppp0_masq (1 references) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * * 10.75.22.0/24 0.0.0.0/0 0 0 SNAT all -- * * 72.38.139.100 0.0.0.0/0 to:66.11.173.224 But already have a conntrack entry such as: udp 17 175 src=10.75.22.3 dst=AA.BB.CCC.DDD sport=4569 dport=4569 src=AA.BB.CCC.DDD dst=72.38.139.100 sport=4569 dport=4569 [ASSURED] use=1 mark=64 bytes=8097545 The SNATting will never actually happen then? Is there any way, short of stopping the application that is continuing to send the packets to destroy that connection so that it''s recreated with the addresses and mark? b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> On Wed, 2007-05-09 at 16:15 -0700, Tom Eastep wrote: >> Once the conntrack table entry is built, there is no further need of the >> nat table rules. > > Ahhh. So you are saying that conntrack then does the natting necessary?Yes.> > So if I add a new rule such as: > > root@wireless:~# iptables -t mangle -I tcpre -p udp --dport 4569 -j MARK --set-mark 0x80 > > So that it gets SNATted with the right source address with: > > Chain ppp0_masq (1 references) > pkts bytes target prot opt in out source destination > 0 0 MASQUERADE all -- * * 10.75.22.0/24 0.0.0.0/0 > 0 0 SNAT all -- * * 72.38.139.100 0.0.0.0/0 to:66.11.173.224 > > But already have a conntrack entry such as: > > udp 17 175 src=10.75.22.3 dst=AA.BB.CCC.DDD sport=4569 dport=4569 src=AA.BB.CCC.DDD dst=72.38.139.100 sport=4569 dport=4569 [ASSURED] use=1 mark=64 bytes=8097545 > > The SNATting will never actually happen then?Once a conntrack entry is fully populated, the connections NAT properties won''t change. Is there any way, short> of stopping the application that is continuing to send the packets to > destroy that connection so that it''s recreated with the addresses and > mark?You can use a tool like ''cutter''. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, 2007-05-09 at 16:32 -0700, Tom Eastep wrote:> > Yes.Cool. This was a detail I did not know about.> Once a conntrack entry is fully populated, the connections NAT > properties won''t change.Right. Gotta get that conntrack entry outta there.> You can use a tool like ''cutter''.There is even a tool for manipulating conntrack entries called, surprisingly enough "conntrack" which let''s on delete conntrack entries. Just trying to find an ipk for openwrt now. Hope I don''t have to roll my own. :-/ b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> On Wed, 2007-05-09 at 16:32 -0700, Tom Eastep wrote: >> Yes. > > Cool. This was a detail I did not know about. > >> Once a conntrack entry is fully populated, the connections NAT >> properties won''t change. > > Right. Gotta get that conntrack entry outta there. > >> You can use a tool like ''cutter''. > > There is even a tool for manipulating conntrack entries called, > surprisingly enough "conntrack" which let''s on delete conntrack entries. > Just trying to find an ipk for openwrt now. Hope I don''t have to roll > my own. :-/I didn''t mention that since you are running a 2.4 kernel -- I would be astonished if conntrack works in that environment. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, 2007-05-09 at 16:52 -0700, Tom Eastep wrote:> Brian J. Murrell wrote: > > I didn''t mention that since you are running a 2.4 kernel -- I would be > astonished if conntrack works in that environment.Yes, indeed, so I am coming to discover. Pity. Unfortunately cutter seems to work only for TCP as it fiddles with the TCP state. The connection I''m trying to break is UDP. Even filtering rules on the gateway are of no help as they seem to take place after the conntrack state is updated. :-( This is quite a predicament. The only way to solve it, assuming I don''t have control of the application generating the traffic going through the firewall is to reboot the firewall. :-( b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> On Wed, 2007-05-09 at 16:52 -0700, Tom Eastep wrote: >> Brian J. Murrell wrote: >> >> I didn''t mention that since you are running a 2.4 kernel -- I would be >> astonished if conntrack works in that environment. > > Yes, indeed, so I am coming to discover. Pity. > > Unfortunately cutter seems to work only for TCP as it fiddles with the > TCP state. The connection I''m trying to break is UDP. > > Even filtering rules on the gateway are of no help as they seem to take > place after the conntrack state is updated. :-( > > This is quite a predicament. The only way to solve it, assuming I don''t > have control of the application generating the traffic going through the > firewall is to reboot the firewall. :-(Or unload to conntrack kernel module. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, 2007-05-09 at 16:05 -0700, Tom Eastep wrote:> Brian J. Murrell wrote: > > On Wed, 2007-05-09 at 07:23 -0700, Tom Eastep wrote: > >> Brian J. Murrell wrote: > >> > >>> Any ideas? > >>> > >> "shorewall dump" output, please. > > > > [ sent ] > > > > But I was looking (with tcpdump) at what was leaving the ppp0 interface > > and noticed that there are packets with a source address of the vlan2 > > interface leaving, which is wrong. So to the nat table I go and see > > this: > > > > Chain POSTROUTING (policy ACCEPT 1862 packets, 195K bytes) > > pkts bytes target prot opt in out source destination > > 0 0 ppp0_masq all -- * ppp0 0.0.0.0/0 0.0.0.0/0 > > 10773 912K vlan2_masq all -- * vlan2 0.0.0.0/0 0.0.0.0/0 > > > > It seems that no packets are matching that "out: ppp0" rule, although I > > can most definitely see packets leaving that interface with tcpdump. > > Only packets in the NEW state traverse the nat table.I wonder if this was my problem all along. It does seem to be gone now. What I was attempting this morning, with SSH seems to have disappeared and is working just fine now. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> > I wonder if this was my problem all along. It does seem to be gone now. > What I was attempting this morning, with SSH seems to have disappeared > and is working just fine now. >Easy trap to fall into... -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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Wed, May 09, 2007 at 05:02:45PM -0700, Tom Eastep wrote:> Brian J. Murrell wrote: > > On Wed, 2007-05-09 at 16:52 -0700, Tom Eastep wrote: > >> Brian J. Murrell wrote: > >> > >> I didn''t mention that since you are running a 2.4 kernel -- I would be > >> astonished if conntrack works in that environment.The specific requirement is for CONFIG_NETFILTER_NETLINK. I''m not sure when that first appeared, but it''s not included in the kernel.org 2.4 kernels.> > This is quite a predicament. The only way to solve it, assuming I don''t > > have control of the application generating the traffic going through the > > firewall is to reboot the firewall. :-( > > Or unload to conntrack kernel module.You can also set /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout to something small and then physically remove the network cable for longer than that period of time. That should cause everything UDP in the conntrack table to expire, without causing significant interruption to TCP sessions, and it''s present in 2.4. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Brian J. Murrell wrote:> On Wed, 2007-05-09 at 16:52 -0700, Tom Eastep wrote: >> Brian J. Murrell wrote: >> >> I didn''t mention that since you are running a 2.4 kernel -- I would be >> astonished if conntrack works in that environment. > > Yes, indeed, so I am coming to discover. Pity. > > Unfortunately cutter seems to work only for TCP as it fiddles with the > TCP state. The connection I''m trying to break is UDP. > > Even filtering rules on the gateway are of no help as they seem to take > place after the conntrack state is updated. :-( > > This is quite a predicament. The only way to solve it, assuming I don''t > have control of the application generating the traffic going through the > firewall is to reboot the firewall. :-(With UDP, there is no connection to break. The conntrack module tracks related UDP packets, but cutter has no relevance to UDP since it is connectionless. -- Paul <http://paulgear.webhop.net> -- Did you know? Email viruses spread using addresses they find on the host computer. You can help to reduce the spread of these viruses by using Bcc: instead of To: on mass mailings, or using mailing list software such as mailman (http://www.list.org/) instead. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Thu, 2007-05-17 at 09:15 +1000, Paul Gear wrote:> With UDP, there is no connection to break.Right. There is a conntrack association with the addr:port tuple though that prevents changes in tables from affecting it''s NAT mappings.> The conntrack module tracks > related UDP packets, but cutter has no relevance to UDP since it is > connectionless.Right. That is what I was already saying. While cutter can break a conntrack entry for TCP because iptables removes the conntrack when it sees the RST packets, no such thing exists for UDP. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Hi! I have a problem with multi-isp config. When I exec "shorewall restart" I receive the following response: ERROR: Can''t determine the IP address of eth7. Before exec that, I have the eth7''s config OK, but after run "shorewall restart" the eth7 lose the config. (?!) My config are: /etc/shorewall/zones fw firewall net ipv4 dmz ipv4 loc ipv4 /etc/shorewall/providers ISP1 1 1 main eth4 detect track,balance eth5,eth8,eth9,eth10 ISP2 2 2 main eth7 gw_ip track,balance eth5,eth8,eth9,eth10 /etc/shorewall/interfaces net eth7 detect net eth4 detect loc eth10 detect ... dmz eth8 detect The eths 5, 8, 9 and 10 are other zones. shorewall version 3.0.4 running in Ubuntu Dapper. Plz, help!! Best wishes!! Barreras ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
J. R. Barreras wrote:> Hi! > I have a problem with multi-isp config. > When I exec "shorewall restart" I receive the following response: ERROR: > Can''t determine the IP address of eth7. > Before exec that, I have the eth7''s config OK, but after run "shorewall > restart" the eth7 lose the config. (?!) > My config are:> > The eths 5, 8, 9 and 10 are other zones. > shorewall version 3.0.4 running in Ubuntu Dapper.I''m going to need a tarball of your /etc/shorewall directory AND a trace of "shorewall restart" to be able to do anything with this report. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> J. R. Barreras wrote: >> Hi! >> I have a problem with multi-isp config. >> When I exec "shorewall restart" I receive the following response: ERROR: >> Can''t determine the IP address of eth7. >> Before exec that, I have the eth7''s config OK, but after run "shorewall >> restart" the eth7 lose the config. (?!) >> My config are: > >> The eths 5, 8, 9 and 10 are other zones. >> shorewall version 3.0.4 running in Ubuntu Dapper. > > I''m going to need a tarball of your /etc/shorewall directory AND a trace of > "shorewall restart" to be able to do anything with this report.And if it turns out to be a Shorewall bug, then I''m going to have to ask you to upgrade since 3.0.4 is no longer a supported Shorewall release. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> > And if it turns out to be a Shorewall bug, then I''m going to have to ask you > to upgrade since 3.0.4 is no longer a supported Shorewall release. >I beg your pardon. Shorewall 3.0.4 *is* still supported. The problem, however, is unlikely to be in Multi-ISP but rather has to do with either /etc/shorewall/nat or /etc/shorewall/masq and the ADD_IP_ALIASES or ADD_SNAT_ALIASES options. If you have set either of these two options to ''Yes'' in shorewall.conf, then with Shorewall 3.0, you must exercise care that you exclude the primary IP address on each interface from the effects of the option. Example: /etc/shorewall/masq WRONG with ADD_SNAT_ALIASES=Yes eth0 eth1 <eth0-primary-ip> RIGHT with ADD_SNAT_ALIASES=Yes eth0: eth1 <eth0-primary-ip> With /etc/shorewall/nat, the primary IP address of an interface should never appear in the EXTERNAL column. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Tom Eastep wrote: > >> And if it turns out to be a Shorewall bug, then I''m going to have to ask you >> to upgrade since 3.0.4 is no longer a supported Shorewall release. >> > > I beg your pardon. Shorewall 3.0.4 *is* still supported.Sigh; I shouldn''t write emails before I''ve had my coffee -- I was right the first time. From http://www.shorewall.net/support.htm: The three currently-supported Shorewall major releases are 3.2, 3.4 and 4.0. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
No problem! I update the OS, but the Shorewall version included in Ubuntu Dapper is 3.0.4. :(( Anyway, I''ll try your previous advices. Thanks! Tom Eastep escribió:> Tom Eastep wrote: > >> Tom Eastep wrote: >> >> >>> And if it turns out to be a Shorewall bug, then I''m going to have to ask you >>> to upgrade since 3.0.4 is no longer a supported Shorewall release. >>> >>> >> I beg your pardon. Shorewall 3.0.4 *is* still supported. >> > > Sigh; I shouldn''t write emails before I''ve had my coffee -- I was right the > first time. From http://www.shorewall.net/support.htm: > > The three currently-supported Shorewall major releases are 3.2, 3.4 > and 4.0. > > -Tom > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- --------------------------------- M.Sc. José Raúl Barreras M. J'' Seguridad Informática G3security Cia. Ltda. 02-2260-947 / 02-2453-700 barreras@g3security.com http://www.g3security.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/