Hi! My _test_ - LAN looks like this: 192.168.2.0/24 | Host1 with 192.168.2.1 | Gateway (eth0) with 192.168.2.91 Gateway (eth1) | Internet | Gateway (eth1) with firewall Gateway (eth0) with 10.0.1.10 | | Host2 with 10.0.1.21 10.0.1.0/24 I can do a ping from 192.168.2.1 to 10.0.1.10, but not to 10.0.1.21 and vice versa. /proc/sys/net/ipv4/conf/*/rp_filter are set to "0". /proc/sys/net/ipv4/ip_forward is set to "1". SuSE Linux 7.2 is installed on both gateways. routed is running on both gateways, producing these firewall logs: ------------------------------------------------------------------------------------------ ..... Packet log: input DENY eth0 PROTO=17 10.0.1.10:520 10.0.1.255:520 L=52 S=0x00 I=0 F=0x4000 T=64 (#5) [Same for eth1 with official addresses] ------------------------------------------------------------------------------------------ I use a own _updown.local script to set up the firewall rules: ------------------------------------------------------------------------------------------ up-client:) ipchains -I forward -j ACCEPT -b \ -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK \ -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK ;; down-client:) ipchains -D forward -j ACCEPT -b \ -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK \ -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK ;; ------------------------------------------------------------------------------------------ What do you think, might be the problem? -- CU, Christoph
On Thursday, 16. August 2001 14:26, egger@mlcomputing.de wrote:
Hi!
My _test_ - LAN looks like this:
192.168.2.0/24
| Host1 with 192.168.2.1
Gateway (eth0) with 192.168.2.91 Gateway (eth1)
Internet
Gateway (eth1) with firewall Gateway (eth0) with 10.0.1.10
| Host2 with 10.0.1.21
10.0.1.0/24
I can do a ping from 192.168.2.1 to 10.0.1.10, but not to 10.0.1.21 and vice versa.
/proc/sys/net/ipv4/conf/*/rp_filter are set to "0". /proc/sys/net/ipv4/ip_forward is set to "1".
SuSE Linux 7.2 is installed on both gateways.
routed is running on both gateways, producing these firewall logs: --------------------------------------------------------------------------- ..... Packet log: input DENY eth0 PROTO=17 10.0.1.10:520 10.0.1.255:520 L=52 S=0x00 I=0 F=0x4000 T=64 (#5) [Same for eth1 with official addresses] ---------------------------------------------------------------------------
I use a own _updown.local script to set up the firewall rules: --------------------------------------------------------------------------- up-client:) ipchains -I forward -j ACCEPT -b \ -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK \ -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK ;; down-client:) ipchains -D forward -j ACCEPT -b \ -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK \ -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK ;; ---------------------------------------------------------------------------
What do you think, might be the problem?
I forgot to mention, that the SuSE firewall 7.2 definitely causes my problem. FreeSWAN works fine for me as long as the firewall is down. But calling "/etc/init.d/SuSEfirewall_init start" and restarting FreeSWAN to not loose its firewall rules already causes my problem. -- CU, Christoph
Hi Christoph On 2001.08.16 15:35:07 +0100 Christoph Egger wrote:
On Thursday, 16. August 2001 14:26, egger@mlcomputing.de wrote:
Hi!
What do you think, might be the problem?
I forgot to mention, that the SuSE firewall 7.2 definitely causes my problem.
FreeSWAN works fine for me as long as the firewall is down. But calling "/etc/init.d/SuSEfirewall_init start" and restarting FreeSWAN to not loose its firewall rules already causes my problem.
Sounds like you may be having some sort of masquerading problem. Have a look in yuor logs and see what packets the firewall drops. HTH, Maf.
-- CU, Christoph
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maf. King Standby Exhibition Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "It is easier to do a job right than to explain why you didn't." - Martin Van Buren ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Thursday, 16. August 2001 17:41, maf@cybereye.co.uk wrote:
Hi Christoph
On 2001.08.16 15:35:07 +0100 Christoph Egger wrote:
On Thursday, 16. August 2001 14:26, egger@mlcomputing.de wrote:
Hi!
What do you think, might be the problem?
I forgot to mention, that the SuSE firewall 7.2 definitely causes my problem.
FreeSWAN works fine for me as long as the firewall is down. But calling "/etc/init.d/SuSEfirewall_init start" and restarting FreeSWAN to not loose its firewall rules already causes my problem.
Sounds like you may be having some sort of masquerading problem. Have a look in yuor logs and see what packets the firewall drops.
Masquerading isn't activated at all. -- CU, Christoph
On Friday, 17. August 2001 09:20, egger@mlcomputing.de wrote:
On Thursday, 16. August 2001 17:41, maf@cybereye.co.uk wrote:
Hi Christoph
On 2001.08.16 15:35:07 +0100 Christoph Egger wrote:
On Thursday, 16. August 2001 14:26, egger@mlcomputing.de wrote:
Hi!
Problem description: -------------------------------------------------------------------------------
My _test_ - LAN looks like this:
192.168.2.0/24
| Host1 with 192.168.2.1
Gateway 1 (eth0) with 192.168.2.91 Gateway 1 (eth1)
Internet
Gateway 2 (eth1) with SuSE 7.2 firewall Gateway 2 (eth0) with 10.0.1.10
| Host2 with 10.0.1.21
10.0.1.0/24
I can do a ping from 192.168.2.1 to 10.0.1.10, but not to 10.0.1.21 and vice versa. It seems that the gateway 2 swellows packets.
What do you think, might be the problem?
I forgot to mention, that the SuSE firewall 7.2 definitely causes my problem.
FreeSWAN works fine for me as long as the firewall is down. But calling "/etc/init.d/SuSEfirewall_init start" and restarting FreeSWAN to not loose its firewall rules already causes my problem.
Sounds like you may be having some sort of masquerading problem. Have a look in yuor logs and see what packets the firewall drops.
Masquerading isn't activated at all.
Here more details: I am using the 2.4.4-4GB Suse standard kernel coming with SuSE 7.2 distribution. The SuSE firewall sets some values in various files in /proc/sys/net/ipv4/ echo 1 > icmp_echo_ignore_broadcasts echo 1 > typ_syncookies echo 1 > ip_always_defrag echo 0 > conf/*/accept_redirects echo 0 > conf/*/accept_source_route echo 1 > icmp_ignore_bogus_error_responses echo 5 > icmp_echoreply_rate echo 5 > icmp_destunreach_rate echo 5 > icmp_paramprob_rate echo 6 > icmp_timeexceed_rate echo 20 > ipfrage_time echo 1 > igmp_max_memberships echo "1024 29999" > ip_local_port_range echo 1 > conf/*/log_martians echo 0 > conf/*/mc_forwarding echo 1 > conf/*/rp_filter (manually disabled by me to keep it "0") echo 0 > conf/*/bootp_relay echo 0 > conf/*/proxy_arp echo 0 > conf/*/secure_redirects echo 1 > route/flush Is there something, which might cause my above described problem? -- CU, Christoph
On Friday, 17. August 2001 12:52, egger@mlcomputing.de wrote:
On Friday, 17. August 2001 09:20, egger@mlcomputing.de wrote:
On Thursday, 16. August 2001 17:41, maf@cybereye.co.uk wrote:
Hi Christoph
On 2001.08.16 15:35:07 +0100 Christoph Egger wrote:
On Thursday, 16. August 2001 14:26, egger@mlcomputing.de wrote:
Hi!
Problem description: --------------------------------------------------------------------------- ----
My _test_ - LAN looks like this:
192.168.2.0/24
| Host1 with 192.168.2.1
Gateway 1 (eth0) with 192.168.2.91 Gateway 1 (eth1)
Internet
Gateway 2 (eth1) with SuSE 7.2 firewall Gateway 2 (eth0) with 10.0.1.10
| Host2 with 10.0.1.21
10.0.1.0/24
Within Gateway 1 (eth1) and Gateway 2 (eth1) there is a IPsec tunnel created by FreeSWAN 1.91.
I can do a ping from 192.168.2.1 to 10.0.1.10, but not to 10.0.1.21 and vice versa. It seems that the gateway 2 swellows packets.
Further the routed is somehow blocked by the firewall: .... Kernel log: input DENY eth0 PROTO=17 10.0.1.0:520 10.0.1.255:520 L=52 S=0x00 I=0 F=0x4000 T=64 (#4) .... Kernel log: input DENY eth1 PROTO=17 62.180.107.61:520 62.180.107.63:520 S=0x00 I=0 F=0x4000 T=64 (#5) Shutting the firewall down, routed says: re-installing interface eth0 re-installing interface eth1 and pinging, DNS, SMB, etc. between the two subnets works perfect.
--------------------------------------------------------------------------- -------
What do you think, might be the problem?
I forgot to mention, that the SuSE firewall 7.2 definitely causes my problem.
FreeSWAN works fine for me as long as the firewall is down. But calling "/etc/init.d/SuSEfirewall_init start" and restarting FreeSWAN to not loose its firewall rules already causes my problem.
Sounds like you may be having some sort of masquerading problem. Have a look in yuor logs and see what packets the firewall drops.
Masquerading isn't activated at all.
Here more details: I am using the 2.4.4-4GB Suse standard kernel coming with SuSE 7.2 distribution.
The SuSE firewall sets some values in various files in /proc/sys/net/ipv4/
echo 1 > icmp_echo_ignore_broadcasts echo 1 > typ_syncookies echo 1 > ip_always_defrag echo 0 > conf/*/accept_redirects echo 0 > conf/*/accept_source_route echo 1 > icmp_ignore_bogus_error_responses echo 5 > icmp_echoreply_rate echo 5 > icmp_destunreach_rate echo 5 > icmp_paramprob_rate echo 6 > icmp_timeexceed_rate echo 20 > ipfrage_time echo 1 > igmp_max_memberships echo "1024 29999" > ip_local_port_range echo 1 > conf/*/log_martians echo 0 > conf/*/mc_forwarding echo 1 > conf/*/rp_filter (manually disabled by me to keep it "0") echo 0 > conf/*/bootp_relay echo 0 > conf/*/proxy_arp echo 0 > conf/*/secure_redirects echo 1 > route/flush
Is there something, which might cause my above described problem?
Hm... no answer to my problem yet. Seems that doesn't help. So here my SuSE 7.2 firewall (version 4.9) configuration in /etc/rc.config.d/firewall.rc.config FW_DEV_WORLD=eth1 FW_DEV_INT=eth0 FW_DEV_DMZ="" FW_ROUTE="yes" FW_MASQUERADE="no" FW_MASQ_NETS="" FW_PROTECT_FROM_INTERNAL="no" FW_AUTOPROTECT_GLOBAL_SERVICES="yes" FW_SERVICES_EXTERNAL_TCP="" FW_SERVICES_EXTERNAL_UDP="500" FW_SERVICES_EXTERNAL_IP="udp 50" FW_SERVICES_DMZ_TCP="" FW_SERVICES_DMZ_UDP="" FW_SERVICES_DMZ_IP="" FW_SERVICES_INTERNAL_TCP="" FW_SERVICES_INTERNAL_UDP="500" FW_SERVICES_INTERNAL_IP="udp 50" FW_TRUSTED_NETS="" FW_SERVICES_TRUSTED_TCP="" FW_SERVICES_TRUSTED_UDP="" FW_SERVICES_TRUSTED_IP="" FW_SERVICES_TRUSTED_ACL="" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" FW_SERVICE_DNS="no" FW_SERVICE_DHCLIENT="no" FW_SERVICE_DHCPD="no" FW_SERVICE_SAMBA="no" FW_FORWARD_TCP="" FW_FORWARD_UDP="" FW_FORWARD_IP="" FW_FORWARD_MASQ_TCP="" FW_FORWARD_MASQ_UDP="" FW_REDIRECT_TCP="" FW_REDIRECT_UDP="" FW_KERNEL_SECURITY="yes" FW_STOP_KEEP_ROUTING_STATE="yes" FW_ALLOW_PING_FW=yes FW_ALLOW_FW_TRACEROUTE=yes All other variables are set to the default values. I hope, that this is enough, that someone can help me. BTW: Setting FW_AUTOPROTECT_GLOBAL_SERVICES to "no" doesn't solve my problem. -- CU, Christoph
Hi Christoph, On 2001.08.20 08:29:39 +0100 Christoph Egger wrote:
Further the routed is somehow blocked by the firewall:
.... Kernel log: input DENY eth0 PROTO=17 10.0.1.0:520 10.0.1.255:520 L=52 S=0x00 I=0 F=0x4000 T=64 (#4) .... Kernel log: input DENY eth1 PROTO=17 62.180.107.61:520 62.180.107.63:520 S=0x00 I=0 F=0x4000 T=64 (#5)
Shutting the firewall down, routed says:
re-installing interface eth0 re-installing interface eth1
and pinging, DNS, SMB, etc. between the two subnets works perfect.
--------------------------------------------------------------------------- -------
What do you think, might be the problem?
Well, at least we know the tunnel works - the problem is something to do with the firewall. I assume the interfaces 62.180.107.6[1,3] are the public addresses of the gateways Since you are getting routed packets blocked, try: 1. Poke a hole in the FW for UDP port 520 - you can always tweak it later to make it more secure. 2. kill routed and test some static routes. If that still doesn't help, put everything back to 'normal' and grab the FW logs from a failed ping through the tunnel. Feel free to post them directly to me if you don't want to post them to the list.
Hm... no answer to my problem yet. Seems that doesn't help. So here my SuSE 7.2 firewall (version 4.9) configuration in /etc/rc.config.d/firewall.rc.config
Sorry, I have always rolled my own fw scripts - I have never looked at the docs for the SuSE fw package. HTH Maf.
-- CU, Christoph
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maf. King Standby Exhibition Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "It is easier to do a job right than to explain why you didn't." - Martin Van Buren ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Monday, 20. August 2001 10:55, maf@cybereye.co.uk wrote:
Hi Christoph,
On 2001.08.20 08:29:39 +0100 Christoph Egger wrote:
Further the routed is somehow blocked by the firewall:
.... Kernel log: input DENY eth0 PROTO=17 10.0.1.0:520 10.0.1.255:520 L=52 S=0x00 I=0 F=0x4000 T=64 (#4) .... Kernel log: input DENY eth1 PROTO=17 62.180.107.61:520 62.180.107.63:520 S=0x00 I=0 F=0x4000 T=64 (#5)
Shutting the firewall down, routed says:
re-installing interface eth0 re-installing interface eth1
and pinging, DNS, SMB, etc. between the two subnets works perfect.
----------------------------------------------------------------------- ---- -------
> What do you think, might be the problem?
Well, at least we know the tunnel works - the problem is something to do with the firewall.
Exactly.
I assume the interfaces 62.180.107.6[1,3] are the public addresses of the gateways
62.180.107.61 is the public address of gateway 2, where the firewall is set up. 62.180.107.63 is the broadcast address.
Since you are getting routed packets blocked, try: 1. Poke a hole in the FW for UDP port 520 - you can always tweak it later to make it more secure. 2. kill routed and test some static routes.
Has no effect.
If that still doesn't help, put everything back to 'normal' and grab the FW logs from a failed ping through the tunnel. Feel free to post them directly to me if you don't want to post them to the list.
FW log is attached. -- CU, Christoph
Christoph Egger writes:
I forgot to mention, that the SuSE firewall 7.2 definitely causes my problem.
FreeSWAN works fine for me as long as the firewall is down. But calling "/etc/init.d/SuSEfirewall_init start" and restarting FreeSWAN to not loose its firewall rules already causes my problem.
In a non-related FreeSWAN/VPN comment: I had problems with SuSEfirewall 4.5 on a 2.2 series kernel. It wasn't obeying my security rules where I was Masquerade-forwarding connections from my firewall to my web machine on the masqueraded DMZ connection. Machines on the DMZ or internal couldn't reach the web server by going to the firewall on port 80, even though I had specified: 0/0,internal.web.address,http \ 0/0,internal.web.address,https \ Upgrading to SuSEfirewall 4.9 from http://www.suse.de/~marc/SuSE.html did the trick. -- Argentium G. Tiger (agtiger@kc.rr.com) "Walkin' through Hell in a gasoline suit."
On Friday, 17. August 2001 14:46, agtiger@kc.rr.com wrote:
Christoph Egger writes:
I forgot to mention, that the SuSE firewall 7.2 definitely causes my problem.
FreeSWAN works fine for me as long as the firewall is down. But calling "/etc/init.d/SuSEfirewall_init start" and restarting FreeSWAN to not loose its firewall rules already causes my problem.
In a non-related FreeSWAN/VPN comment: I had problems with SuSEfirewall 4.5 on a 2.2 series kernel. It wasn't obeying my security rules where I was Masquerade-forwarding connections from my firewall to my web machine on the masqueraded DMZ connection. Machines on the DMZ or internal couldn't reach the web server by going to the firewall on port 80, even though I had specified:
0/0,internal.web.address,http \ 0/0,internal.web.address,https \
Upgrading to SuSEfirewall 4.9 from http://www.suse.de/~marc/SuSE.html did the trick.
I upgraded, but the problem is still not solved. :-( -- CU, Christoph
participants (3)
-
Argentium G. Tiger -
Christoph Egger -
maf king