thr3ads.net - Shorewall users - shorewall & ipsec -- zone issue? [Jan 2004]

If this information is useful, please help other people find it:
Share via:

Michael Ferraro

2004-Jan-14 22:35 UTC

shorewall & ipsec -- zone issue?

Hi, All

I''m into my 2nd day of trying to diagnose why my IPSEC setup
isn''t
working, and I was hoping somebody would have some insight.  Me
repeatedly banging my head against the wall doesn''t seem to be working
(this time). ;)

I''m trying to set up Super Freeswan (with x.509 certificates) +
Shorewall to build IPSEC tunnels between both (1) the Internet
(zone=net, eth0) and (2) a wireless network (zone=air, eth4), to (3) the
corporate LAN (zone=loc, eth1).  This is a "roadwarrior" setup,
connecting Win2k to Super Freeswan.  I''m using Marcus Muller''s
Win2k
IPSEC tool from <http://vpn.ebootis.de/>.

Involved interfaces:

NET ZONE
eth0      Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
          inet addr:<PUBLIC_IP_1>  Bcast:<PUBLIC_IP_2> 
	Mask:255.255.255.224

LOC ZONE        
eth1      Link encap:Ethernet  HWaddr 00:05:5D:30:15:1C
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0

AIR ZONE
eth4      Link encap:Ethernet  HWaddr 00:C0:4F:79:55:F1
          inet addr:192.168.30.1  Bcast:192.168.30.255 
Mask:255.255.255.0

VPN ZONE 
ipsec0    Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
          inet addr:<PUBLIC_IP_2>  Mask:255.255.255.224


When I create an IPSEC tunnel from a host in the air zone, the traffic
is dropped by Shorewall, which believes the packet is originating from
the air zone -- not the vpn zone I created (configuration details are
below).  I can''t figure out why that traffic is not being considered
part of the vpn zone, even though the KLIPS debug logs show the packets
coming into KLIPS, being de-encapsulated, etc.  So, I allowed all
traffic from air to loc.  I can now see a complete flow between the
involved physical interfaces (using tcpdump), and I can see the
de-encapsulation/re-encapsulation of packets by KLIPS.  However, I never
get a response back at the client when I send ICMP pings.  I''m getting
similar results from an IP in the net zone that the firewall is not
using.  I''m waiting on a laptop that''s been borrowed so I can
try from
an IP in the wild that''s not in our ISP-assigned block, by using a
dialup service.

This is the sequence I''m trying:

(1)  Start the IPSEC tunnel from the host in the air zone to the
firewall''s public IP -- successful, certificate works, SA is good.
(2)  Ping a host in the loc zone -- Win2k ping comes back and says
"Negotiating IP Security"
(3)  Wait a few seconds...
(4)  Ping that same host again -- "request timed out"

Below is my configuration:

--> I''ve set up a vpn zone in /etc/shorewall/zones:

#ZONE   DISPLAY       COMMENTS
net     Net             Internet
loc     Local          Local networks (Corporate Network)
dmz     DMZ             Web Server DMZ
dat     DATA-NET       Data server Network
air     802.11b        802.11b Network
vpn     ipsec0         IPSEC VPN tunnels


--> In /etc/shorewall/policy, I have these lines:
air             loc             ACCEPT          info **
loc             air             ACCEPT          info **
vpn             loc             ACCEPT          info

** ONLY PRESENT BECAUSE IPSEC TRAFFIC ISN''T BEING CLASSIFIED IN
''VPN''
ZONE


--> I added these rules in /etc/shorewall/rules:
##################################################
# ipsec vpn rules                                          #
##################################################
ACCEPT  net                     fw      udp     500
ACCEPT  fw                      net     udp     500  --> unnecessary?
ACCEPT  air                     fw      udp     500
ACCEPT  fw                      air     udp     500  --> unnecessary?
ACCEPT  net                     fw      50
ACCEPT  air                     fw      50
ACCEPT  net                     fw      51
ACCEPT  air                     fw      51


--> /etc/shorewall/interfaces:
net     eth0            detect         
dropunclean,routefilter,norfc1918,blacklist
loc     eth1            detect          dropunclean
dmz     eth2            detect          dropunclean,routeback
dat     eth3            detect          dropunclean
air     eth4            detect          dropunclean
vpn     ipsec0


--> /etc/shorewall/tunnels:
# TYPE                  ZONE    GATEWAY         GATEWAY ZONE    PORT
ipsec                   air     192.168.30.0/24 vpn
ipsec                   net     0.0.0.0/0       vpn


The logging from the Win2k IPSEC client (oakley.log) is very
uninteresting -- it''s not giving any errors.

I''ve provided some logging below.

Thanks in advance!

Regards,
Mike

--

Logging stuff:  (note -- public IP replaced by XX.YY.ZZ.162)

Jan 14 22:27:02 firewall pluto[22877]: | *received 216 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:02 firewall pluto[22877]: packet from 192.168.30.99:500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000002]
Jan 14 22:27:02 firewall pluto[22877]: | instantiated
"w2k-road-warriors-mferraro" for 192.168.30.99
Jan 14 22:27:02 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #1: responding to Main Mode from unknown peer
192.168.30.99
Jan 14 22:27:02 firewall pluto[22877]: | sending 84 bytes for
STATE_MAIN_R0 through eth0 to 192.168.30.99:500:
Jan 14 22:27:02 firewall pluto[22877]: | *received 184 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:02 firewall pluto[22877]: | sending 188 bytes for
STATE_MAIN_R1 through eth0 to 192.168.30.99:500:
Jan 14 22:27:02 firewall pluto[22877]: | *received 1932 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:02 firewall pluto[22877]: | received encrypted packet from
192.168.30.99:500
Jan 14 22:27:03 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #1: Main mode peer ID is ID_DER_ASN1_DN: ''C=US,
ST=California, L=My Town, O=MyComPanYnAmE, OU=Technical Operations,
CN=Michael Ferraro, E=my@email.com''
Jan 14 22:27:04 firewall pluto[22877]: | sending 1764 bytes for
STATE_MAIN_R2 through eth0 to 192.168.30.99:500:
Jan 14 22:27:04 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #1: sent MR3, ISAKMP SA established
Jan 14 22:27:04 firewall pluto[22877]: | *received 1932 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:05 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #1: retransmitting in response to duplicate packet;
already STATE_MAIN_R3
Jan 14 22:27:05 firewall pluto[22877]: | sending 1764 bytes for
retransmit in response to duplicate through eth0 to 192.168.30.99:500:
Jan 14 22:27:05 firewall pluto[22877]: | *received 308 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_ipsec_sa_init: (pfkey
defined) IPIP tdb set for 192.168.30.99->XX.YY.ZZ.162. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:06 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:112 id:2048 frag_off:0 ttl:128 proto:50 chk:63570
saddr:192.168.30.99 daddr:XX.YY.ZZ.162 
Jan 14 22:27:06 firewall kernel: klips_debug:ipsec_rcv:
SA:esp0x67a15c15@XX.YY.ZZ.162, src=192.168.30.99 of pkt agrees with
expected SA source address policy. 
Jan 14 22:27:05 firewall pluto[22877]: | received encrypted packet from
192.168.30.99:500
Jan 14 22:27:05 firewall pluto[22877]: | peer client is 192.168.30.99/32
Jan 14 22:27:05 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #2: responding to Quick Mode
Jan 14 22:27:06 firewall pluto[22877]: | finish_pfkey_msg: SADB_ADD
message 6 for Add IPIP SA tun.1001@192.168.30.99
Jan 14 22:27:06 firewall pluto[22877]: | sending 300 bytes for
STATE_QUICK_R0 through eth0 to 192.168.30.99:500:
Jan 14 22:27:06 firewall pluto[22877]: | *received 308 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:06 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #2: discarding duplicate packet; already STATE_QUICK_R1
Jan 14 22:27:06 firewall pluto[22877]: | *received 52 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:06 firewall kernel: klips_debug:ipsec_rcv: packet from
192.168.30.99 received with seq=1 (iv)=0x3af1f109600ba8f8 iplen=112
esplen=80 sa=esp0x67a15c15@XX.YY.ZZ.162 
Jan 14 22:27:06 firewall kernel: klips_debug:ipsec_rcv: packet decrypted
from 192.168.30.99: next_header = 4, padding = 2 
Jan 14 22:27:06 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:80 id:2048 frag_off:0 ttl:128 proto:4 chk:63648 saddr:192.168.30.99
daddr:XX.YY.ZZ.162 
Jan 14 22:27:06 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:60 id:293 frag_off:0 ttl:128 proto:1 (ICMP) chk:39370
saddr:192.168.30.99 daddr:192.168.0.30 type:code=8:0 
Jan 14 22:27:06 firewall kernel: Shorewall:air2loc:ACCEPT:IN=eth4
OUT=eth1 SRC=192.168.30.99 DST=192.168.0.30 LEN=60 TOS=0x00 PREC=0x00
TTL=127 ID=293 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=5888  
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:gettdb: linked entry in tdb
table for hash=196 of SA:esp0x350b79e4@192.168.30.99 requested. 
Jan 14 22:27:06 firewall kernel: klips_debug:gettdb: no entries in tdb
table for hash=196 of SA:esp0x350b79e4@192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_add_parse: existing
Tunnel Descriptor Block not found (this is good) for
SAesp0x350b79e4@192.168.30.99, out-bound, allocating. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_ipsec_sa_init: (pfkey
defined) called for SA:esp0x350b79e4@192.168.30.99 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_add_parse: successful
for SA: esp0x350b79e4@192.168.30.99 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:gettdb: linked entry in tdb
table for hash=230 of SA:tun0x1002@192.168.30.99 requested. 
Jan 14 22:27:06 firewall kernel: klips_debug:gettdb: no entries in tdb
table for hash=230 of SA:tun0x1002@192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_add_parse: existing
Tunnel Descriptor Block not found (this is good) for
SAtun0x1002@192.168.30.99, out-bound, allocating. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_ipsec_sa_init: (pfkey
defined) called for SA:tun0x1002@192.168.30.99 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_ipsec_sa_init: (pfkey
defined) IPIP tdb set for XX.YY.ZZ.162->192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_add_parse: successful
for SA: tun0x1002@192.168.30.99 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99. 
Jan 14 22:27:06 firewall kernel: klips_debug:gettdb: linked entry in tdb
table for hash=230 of SA:tun0x1002@192.168.30.99 requested. 
Jan 14 22:27:06 firewall kernel: klips_debug:gettdb: linked entry in tdb
table for hash=196 of SA:esp0x350b79e4@192.168.30.99 requested. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:06 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99. 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_address_parse:
extr->eroute set to 192.168.0.0/0:0->192.168.30.99/0:0 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_address_parse:
extr->eroute set to 192.168.0.0/24:0->192.168.30.99/0:0 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_address_parse:
extr->eroute set to 192.168.0.0/24:0->192.168.30.99/32:0 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_x_addflow_parse:
calling breakeroute and/or makeroute for
192.168.0.0/24->192.168.30.99/32 
Jan 14 22:27:07 firewall kernel: klips_debug:ipsec_makeroute: attempting
to insert eroute for 192.168.0.0/24:0->192.168.30.99/32:0 0, SA:
tun0x1002@192.168.30.99, PID:22877, skb=00000000, ident:NULL->NULL 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:07 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:06 firewall pluto[22877]: | received encrypted packet from
192.168.30.99:500
Jan 14 22:27:06 firewall pluto[22877]: | finish_pfkey_msg: SADB_ADD
message 8 for Add ESP SA esp.350b79e4@192.168.30.99
Jan 14 22:27:06 firewall pluto[22877]: | finish_pfkey_msg: SADB_ADD
message 9 for Add IPIP SA tun.1002@192.168.30.99
Jan 14 22:27:06 firewall pluto[22877]: | grouping tun.1002@192.168.30.99
and esp.350b79e4@192.168.30.99
Jan 14 22:27:06 firewall pluto[22877]: | finish_pfkey_msg: SADB_X_GRPSA
message 10 for group tun.1002@192.168.30.99
Jan 14 22:27:06 firewall pluto[22877]: | add eroute 192.168.0.0/24:0 ->
192.168.30.99/32:0 => tun.1002@192.168.30.99:0
Jan 14 22:27:06 firewall pluto[22877]: | finish_pfkey_msg:
SADB_X_ADDFLOW message 11 for flow tun.1002@192.168.30.99
Jan 14 22:27:06 firewall pluto[22877]: | executing up-client: 2>&1
PLUTO_VERSION=''1.1'' PLUTO_VERB=''up-client''
PLUTO_CONNECTION=''w2k-road-warriors-mferraro''
PLUTO_NEXT_HOP=''XX.YY.ZZ.161''
PLUTO_INTERFACE=''ipsec0''
PLUTO_ME=''XX.YY.ZZ.162'' PLUTO_MY_ID=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, CN=FiReWaLLnAmE.here.com,
E=my@email.com'' PLUTO_MY_CLIENT=''192.168.0.0/24''
PLUTO_MY_CLIENT_NET=''192.168.0.0''
PLUTO_MY_CLIENT_MASK=''255.255.255.0''
PLUTO_MY_PORT=''0'' PLUTO_MY_PROTOCOL=''0''
PLUTO_PEER=''192.168.30.99''
PLUTO_PEER_ID=''C=US, ST=California, L=My Town, O=MyComPanYnAmE,
OU=Technical Operations, CN=Michael Ferraro, E=my@email.com''
PLUTO_PEER_CLIENT=''192.168.30.99/32''
PLUTO_PEER_CLIENT_NET=''192.168.30.99''
PLUTO_PEER_CLIENT_MASK=''255.255.255.255''
PLUTO_PEER_PORT=''0''
PLUTO_PEER_PROTOCOL=''0'' PLUTO_PEER_CA=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, E=my@email.com'' ipsec _updown
Jan 14 22:27:06 firewall pluto[22877]: | executing prepare-client: 2>&1
PLUTO_VERSION=''1.1''
PLUTO_VERB=''prepare-client''
PLUTO_CONNECTION=''w2k-road-warriors-mferraro''
PLUTO_NEXT_HOP=''XX.YY.ZZ.161''
PLUTO_INTERFACE=''ipsec0''
PLUTO_ME=''XX.YY.ZZ.162'' PLUTO_MY_ID=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, CN=FiReWaLLnAmE.here.com,
E=my@email.com'' PLUTO_MY_CLIENT=''192.168.0.0/24''
PLUTO_MY_CLIENT_NET=''192.168.0.0''
PLUTO_MY_CLIENT_MASK=''255.255.255.0''
PLUTO_MY_PORT=''0'' PLUTO_MY_PROTOCOL=''0''
PLUTO_PEER=''192.168.30.99''
PLUTO_PEER_ID=''C=US, ST=California, L=My Town, O=MyComPanYnAmE,
OU=Technical Operations, CN=Michael Ferraro, E=my@email.com''
PLUTO_PEER_CLIENT=''192.168.30.99/32''
PLUTO_PEER_CLIENT_NET=''192.168.30.99''
PLUTO_PEER_CLIENT_MASK=''255.255.255.255''
PLUTO_PEER_PORT=''0''
PLUTO_PEER_PROTOCOL=''0'' PLUTO_PEER_CA=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, E=my@email.com'' ipsec _updown
Jan 14 22:27:06 firewall pluto[22877]: | executing route-client: 2>&1
PLUTO_VERSION=''1.1''
PLUTO_VERB=''route-client''
PLUTO_CONNECTION=''w2k-road-warriors-mferraro''
PLUTO_NEXT_HOP=''XX.YY.ZZ.161''
PLUTO_INTERFACE=''ipsec0''
PLUTO_ME=''XX.YY.ZZ.162'' PLUTO_MY_ID=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, CN=FiReWaLLnAmE.here.com,
E=my@email.com'' PLUTO_MY_CLIENT=''192.168.0.0/24''
PLUTO_MY_CLIENT_NET=''192.168.0.0''
PLUTO_MY_CLIENT_MASK=''255.255.255.0''
PLUTO_MY_PORT=''0'' PLUTO_MY_PROTOCOL=''0''
PLUTO_PEER=''192.168.30.99''
PLUTO_PEER_ID=''C=US, ST=California, L=My Town, O=MyComPanYnAmE,
OU=Technical Operations, CN=Michael Ferraro, E=my@email.com''
PLUTO_PEER_CLIENT=''192.168.30.99/32''
PLUTO_PEER_CLIENT_NET=''192.168.30.99''
PLUTO_PEER_CLIENT_MASK=''255.255.255.255''
PLUTO_PEER_PORT=''0''
PLUTO_PEER_PROTOCOL=''0'' PLUTO_PEER_CA=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, E=my@email.com'' ipsec _updown
Jan 14 22:27:06 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #2: IPsec SA established
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:112 id:2304 frag_off:0 ttl:128 proto:50 chk:63314
saddr:192.168.30.99 daddr:XX.YY.ZZ.162 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_rcv:
SA:esp0x67a15c15@XX.YY.ZZ.162, src=192.168.30.99 of pkt agrees with
expected SA source address policy. 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_rcv: packet from
192.168.30.99 received with seq=2 (iv)=0x5f6b516537032fc2 iplen=112
esplen=80 sa=esp0x67a15c15@XX.YY.ZZ.162 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_rcv: packet decrypted
from 192.168.30.99: next_header = 4, padding = 2 
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:80 id:2304 frag_off:0 ttl:128 proto:4 chk:63392 saddr:192.168.30.99
daddr:XX.YY.ZZ.162 
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:60 id:301 frag_off:0 ttl:128 proto:1 (ICMP) chk:39362
saddr:192.168.30.99 daddr:192.168.0.30 type:code=8:0 
Jan 14 22:27:12 firewall kernel: Shorewall:air2loc:ACCEPT:IN=eth4
OUT=eth1 SRC=192.168.30.99 DST=192.168.0.30 LEN=60 TOS=0x00 PREC=0x00
TTL=127 ID=301 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=6144  
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:60 id:51413 frag_off:0 ttl:63 proto:1 (ICMP) chk:4890
saddr:192.168.0.30 daddr:192.168.30.99 type:code=0:0 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_findroute:
192.168.0.30:0->192.168.30.99:0 1 
Jan 14 22:27:12 firewall kernel: klips_debug:gettdb: linked entry in tdb
table for hash=230 of SA:tun0x1002@192.168.30.99 requested. 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_tunnel_start_xmit:
found Tunnel Descriptor Block -- SA:<IPIP> tun0x1002@192.168.30.99 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_tunnel_start_xmit:
calling room for <IPIP>, SA:tun0x1002@192.168.30.99 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_tunnel_start_xmit:
calling room for <ESP_3DES_HMAC_MD5>, SA:esp0x350b79e4@192.168.30.99 
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:60 id:51413 frag_off:0 ttl:63 proto:1 (ICMP) chk:4890
saddr:192.168.0.30 daddr:192.168.30.99 type:code=0:0 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_tunnel_start_xmit:
calling output for <IPIP>, SA:tun0x1002@192.168.30.99 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_tunnel_start_xmit:
after <IPIP>, SA:tun0x1002@192.168.30.99: 
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:80 id:17916 frag_off:0 ttl:64 proto:4 chk:64164 saddr:XX.YY.ZZ.162
daddr:192.168.30.99 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_tunnel_start_xmit:
calling output for <ESP_3DES_HMAC_MD5>, SA:esp0x350b79e4@192.168.30.99 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_tunnel_start_xmit:
after <ESP_3DES_HMAC_MD5>, SA:esp0x350b79e4@192.168.30.99: 
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:112 id:17916 frag_off:0 ttl:64 proto:50 chk:64086
saddr:XX.YY.ZZ.162 daddr:192.168.30.99 
Jan 14 22:27:12 firewall kernel: klips_debug:ipsec_findroute:
XX.YY.ZZ.162:0->192.168.30.99:0 50 
Jan 14 22:27:12 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:112 id:17916 frag_off:0 ttl:64 proto:50 chk:64086
saddr:XX.YY.ZZ.162 daddr:192.168.30.99 
Jan 14 22:27:17 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:96 id:54110 DF frag_off:0 ttl:64 proto:17 (UDP) chk:11557
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500 
Jan 14 22:27:17 firewall kernel: klips_debug:ipsec_findroute:
XX.YY.ZZ.162:500->192.168.30.99:500 17 
Jan 14 22:27:17 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:96 id:54110 DF frag_off:0 ttl:64 proto:17 (UDP) chk:11557
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99. 
Jan 14 22:27:17 firewall kernel: klips_debug:gettdb: linked entry in tdb
table for hash=196 of SA:esp0x350b79e4@192.168.30.99 requested. 
Jan 14 22:27:17 firewall kernel: klips_debug:deltdbchain: passed
SA:esp0x350b79e4@192.168.30.99 
Jan 14 22:27:17 firewall kernel: klips_debug:deltdbchain: unlinking and
delting SA:esp0x350b79e4@192.168.30.99<6>,
inext=tun0x1002@192.168.30.99<6>. 
Jan 14 22:27:17 firewall kernel: klips_debug:deltdb: deleting
SA:esp0x350b79e4@192.168.30.99, hashval=196. 
Jan 14 22:27:17 firewall kernel: klips_debug:deltdbchain: unlinking and
delting SA:tun0x1002@192.168.30.99<6>. 
Jan 14 22:27:17 firewall kernel: klips_debug:deltdb: deleting
SA:tun0x1002@192.168.30.99, hashval=230. 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:17 firewall pluto[22877]: | *received 68 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:17 firewall pluto[22877]: | received encrypted packet from
192.168.30.99:500
Jan 14 22:27:17 firewall pluto[22877]: "w2k-road-warriors-mferraro"[1]
192.168.30.99 #1: received Delete SA payload: deleting IPSEC State #2
Jan 14 22:27:17 firewall pluto[22877]: | sending 68 bytes for delete
notify through eth0 to 192.168.30.99:500:
Jan 14 22:27:17 firewall pluto[22877]: | executing down-client: 2>&1
PLUTO_VERSION=''1.1'' PLUTO_VERB=''down-client''
PLUTO_CONNECTION=''w2k-road-warriors-mferraro''
PLUTO_NEXT_HOP=''XX.YY.ZZ.161''
PLUTO_INTERFACE=''ipsec0''
PLUTO_ME=''XX.YY.ZZ.162'' PLUTO_MY_ID=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, CN=FiReWaLLnAmE.here.com,
E=my@email.com'' PLUTO_MY_CLIENT=''192.168.0.0/24''
PLUTO_MY_CLIENT_NET=''192.168.0.0''
PLUTO_MY_CLIENT_MASK=''255.255.255.0''
PLUTO_MY_PORT=''0'' PLUTO_MY_PROTOCOL=''0''
PLUTO_PEER=''192.168.30.99''
PLUTO_PEER_ID=''C=US, ST=California, L=My Town, O=MyComPanYnAmE,
OU=Technical Operations, CN=Michael Ferraro, E=my@email.com''
PLUTO_PEER_CLIENT=''192.168.30.99/32''
PLUTO_PEER_CLIENT_NET=''192.168.30.99''
PLUTO_PEER_CLIENT_MASK=''255.255.255.255''
PLUTO_PEER_PORT=''0''
PLUTO_PEER_PROTOCOL=''0'' PLUTO_PEER_CA=''C=US,
ST=California, L=My Town,
O=MyComPanYnAmE, OU=Technical Operations, E=my@email.com'' ipsec _updown
Jan 14 22:27:17 firewall pluto[22877]: | replace with shunt eroute
192.168.0.0/24:0 -> 192.168.30.99/32:0 => %trap:0
Jan 14 22:27:17 firewall pluto[22877]: | delete
esp.350b79e4@192.168.30.99
Jan 14 22:27:17 firewall pluto[22877]: | finish_pfkey_msg: SADB_DELETE
message 13 for Delete SA esp.350b79e4@192.168.30.99
Jan 14 22:27:17 firewall pluto[22877]: | *received 84 bytes from
192.168.30.99:500 on eth0
Jan 14 22:27:17 firewall pluto[22877]: | received encrypted packet from
192.168.30.99:500
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_build: found
address=192.168.30.99:0. 
Jan 14 22:27:17 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:112 id:40735 DF frag_off:0 ttl:64 proto:17 (UDP) chk:24916
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500 
Jan 14 22:27:17 firewall kernel: klips_debug:ipsec_findroute:
XX.YY.ZZ.162:500->192.168.30.99:500 17 
Jan 14 22:27:17 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:112 id:40735 DF frag_off:0 ttl:64 proto:17 (UDP) chk:24916
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99. 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_parse:
extr->eroute set to 192.168.0.0/0:0->192.168.30.99/0:0 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_parse:
extr->eroute set to 192.168.0.0/24:0->192.168.30.99/0:0 
Jan 14 22:27:17 firewall kernel: klips_debug:pfkey_address_parse:
extr->eroute set to 192.168.0.0/24:0

Tom Eastep

2004-Jan-14 22:54 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wednesday 14 January 2004 02:35 pm, Michael Ferraro wrote:
>
> When I create an IPSEC tunnel from a host in the air zone, the traffic
> is dropped by Shorewall, which believes the packet is originating from
> the air zone -- not the vpn zone I created (configuration details are
> below).  I can''t figure out why that traffic is not being
considered
> part of the vpn zone, even though the KLIPS debug logs show the packets
> coming into KLIPS, being de-encapsulated, etc.
Now what did you really intend to say above -- because what you wrote makes no 
sense. I suspect that the first sentence was supposed to be:

	"When I create an IPSEC tunnel from a host in the vpn zone.."
> So, I allowed all traffic from air to loc. 
Stop right there -- do not allow all traffic from air to loc and post some 
Shorewall log messages so we can see why that is happening.

Also, what kernel version are you running on the firewall?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Michael Ferraro

2004-Jan-15 00:01 UTC

head link

Re: shorewall & ipsec -- zone issue?

Hi, Tom

My sentence is correct -- I''m trying to establish an IPSEC connection
from 192.168.30.99, a host which happens to reside in the AIR zone, to
the firewall, in order to have secure access to the LOC zone,
192.168.0.0/24.  Since I''m establishing an IPSEC connection, and the
traffic is going through it (I believe -- that''s what the logs below
indicate, as far as I can tell), I would expect that this would be
considered VPN zone traffic, as far as Shorewall is concerned.  Please
correct me if I''m mistaken.

The purpose of what I''m doing is this:  the AIR zone is an 802.11b
network, and we may have untrusted hosts on it from time to time (office
visitors).  I want our users, when they''re connected on the AIR
network,
to be able to establish an IPSEC tunnel to the firewall so that they can
have blanket access to the LOC network -- something that I do not allow
from AIR, but would from VPN.

The firewall is running kernel 2.4.20.  

I''ve dropped air<->loc traffic, per below.

/etc/shorewall/policy:
<snip>
air            loc              DROP             info
loc            air              DROP             info
vpn             loc             ACCEPT          info
loc             vpn             ACCEPT          info
</snip>

Log excerpts:

Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv:
SA:esp0xe3416e09@XX.YY.ZZ.162, src=192.168.30.99 of pkt agrees with
expected SA source address policy.
Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv: packet from
192.168.30.99 received with seq=2 (iv)=0x2d51cda1d28d7c1f iplen=112
esplen=80 sa=esp0xe3416e09@XX.YY.ZZ.162
Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv: packet decrypted
from 192.168.30.99: next_header = 4, padding = 2
Jan 14 23:54:00 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:80 id:5632 frag_off:0 ttl:128 proto:4 chk:60064 saddr:192.168.30.99
daddr:XX.YY.ZZ.162
Jan 14 23:54:00 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:60 id:892 frag_off:0 ttl:128 proto:1 (ICMP) chk:38771
saddr:192.168.30.99 daddr:192.168.0.30 type:code=8:0

*****
Jan 14 23:54:00 firewall kernel: Shorewall:air2loc:DROP:IN=eth4 OUT=eth1
SRC=192.168.30.99 DST=192.168.0.30 LEN=60 TOS=0x00 PREC=0x00 TTL=127
ID=892 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=17408
*****

Jan 14 23:54:05 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:96 id:26064 DF frag_off:0 ttl:64 proto:17 (UDP) chk:39603
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500
Jan 14 23:54:05 firewall kernel: klips_debug:ipsec_findroute:
XX.YY.ZZ.162:500->192.168.30.99:500 17
Jan 14 23:54:05 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:96 id:26064 DF frag_off:0 ttl:64 proto:17 (UDP) chk:39603
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500
Jan 14 23:54:05 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99.
Jan 14 23:54:05 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99.



Thanks,
Mike

Tom Eastep

2004-Jan-15 00:14 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wednesday 14 January 2004 04:01 pm, Michael Ferraro
wrote:> Hi, Tom
>
> My sentence is correct -- I''m trying to establish an IPSEC
connection
> from 192.168.30.99, a host which happens to reside in the AIR zone, to
> the firewall, in order to have secure access to the LOC zone,
> 192.168.0.0/24.  Since I''m establishing an IPSEC connection, and
the
> traffic is going through it (I believe -- that''s what the logs
below
> indicate, as far as I can tell), I would expect that this would be
> considered VPN zone traffic, as far as Shorewall is concerned.  Please
> correct me if I''m mistaken.
>
> The purpose of what I''m doing is this:  the AIR zone is an 802.11b
> network, and we may have untrusted hosts on it from time to time (office
> visitors).  I want our users, when they''re connected on the AIR
network,
> to be able to establish an IPSEC tunnel to the firewall so that they can
> have blanket access to the LOC network -- something that I do not allow
> from AIR, but would from VPN.
>
> The firewall is running kernel 2.4.20.
Do you even have an ipsec0 when your tunnel is up? Or are you using the 
cryptoapi code ported from the 2.6 kernels that doesn''t use
ipsec<n> devices?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Michael Ferraro

2004-Jan-15 00:16 UTC

head link

Re: shorewall & ipsec -- zone issue?

ipsec0 is present when the ipsec service is running.

Mike



# ifconfig ipsec0
ipsec0    Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
          inet addr:XX.YY.ZZ.162  Mask:255.255.255.224
          UP RUNNING NOARP  MTU:16260  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          Collisions:0
 
 
sid: -root-
# svi ipsec stop
ipsec_setup: Stopping FreeS/WAN IPsec...
 
sid: -root-
# ifconfig ipsec0
ipsec0: unknown interface.

Tom Eastep

2004-Jan-15 00:23 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wednesday 14 January 2004 04:16 pm, Michael Ferraro
wrote:> ipsec0 is present when the ipsec service is running.
>
> Mike
>
>
>
> # ifconfig ipsec0
> ipsec0    Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
>           inet addr:XX.YY.ZZ.162  Mask:255.255.255.224
>           UP RUNNING NOARP  MTU:16260  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
>           Collisions:0
>
>
> sid: -root-
> # svi ipsec stop
> ipsec_setup: Stopping FreeS/WAN IPsec...
>
> sid: -root-
> # ifconfig ipsec0
> ipsec0: unknown interface.
Well the reason that Shorewall thinks the packets are coming from the
''air''
zone is because they *are* coming from the ''air'' zone:

Jan 14 23:54:00 firewall kernel: Shorewall:air2loc:DROP:IN=eth4 OUT=eth1
SRC=192.168.30.99 DST=192.168.0.30 LEN=60 TOS=0x00 PREC=0x00 TTL=127
ID=892 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=17408

The are coming in on eth4, not ipsec0.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Tom Eastep

2004-Jan-15 00:34 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wed, 14 Jan 2004, Tom Eastep wrote:
> On Wednesday 14 January 2004 04:16 pm, Michael Ferraro wrote:
> > ipsec0 is present when the ipsec service is running.
> >
> > Mike
> >
> >
> >
> > # ifconfig ipsec0
> > ipsec0    Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
> >           inet addr:XX.YY.ZZ.162  Mask:255.255.255.224
> >           UP RUNNING NOARP  MTU:16260  Metric:1
> >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> >           Collisions:0
> >
> >
> > sid: -root-
> > # svi ipsec stop
> > ipsec_setup: Stopping FreeS/WAN IPsec...
> >
> > sid: -root-
> > # ifconfig ipsec0
> > ipsec0: unknown interface.
>
> Well the reason that Shorewall thinks the packets are coming from the
''air''
> zone is because they *are* coming from the ''air'' zone:
>
> Jan 14 23:54:00 firewall kernel: Shorewall:air2loc:DROP:IN=eth4 OUT=eth1
> SRC=192.168.30.99 DST=192.168.0.30 LEN=60 TOS=0x00 PREC=0x00 TTL=127
> ID=892 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=17408
>
> The are coming in on eth4, not ipsec0.
>
Simply stated, this means that the system at the other end of the tunnel
isn''t routing traffic for 192.168.0.30 through the tunnel.

-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Michael Ferraro

2004-Jan-15 00:36 UTC

head link

Re: shorewall & ipsec -- zone issue?

Tom,

Looking at the logs I sent along with my second-to-last message
(reposted below), the packet is being picked up by the tunnel, being
decrypted, de-encapsulated, and then sent to the desired host,
192.168.0.30 -- the one I''m trying to ICMP ping.

At that point, Shorewall is seeing that the "IN" device is eth4, as
you
pointed out.  Do you suspect the misbehavior is with the ipsec service
or with my shorewall configuration?  Any suggestions for how I might fix
this?

Thanks,
Mike


Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv:
SA:esp0xe3416e09@XX.YY.ZZ.162, src=192.168.30.99 of pkt agrees with
expected SA source address policy.
Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv: packet from
192.168.30.99 received with seq=2 (iv)=0x2d51cda1d28d7c1f iplen=112
esplen=80 sa=esp0xe3416e09@XX.YY.ZZ.162
Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv: packet decrypted
from 192.168.30.99: next_header = 4, padding = 2
Jan 14 23:54:00 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:80 id:5632 frag_off:0 ttl:128 proto:4 chk:60064 saddr:192.168.30.99
daddr:XX.YY.ZZ.162
Jan 14 23:54:00 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:60 id:892 frag_off:0 ttl:128 proto:1 (ICMP) chk:38771
saddr:192.168.30.99 daddr:192.168.0.30 type:code=8:0

*****
Jan 14 23:54:00 firewall kernel: Shorewall:air2loc:DROP:IN=eth4 OUT=eth1
SRC=192.168.30.99 DST=192.168.0.30 LEN=60 TOS=0x00 PREC=0x00 TTL=127
ID=892 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=17408
*****

Jan 14 23:54:05 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:96 id:26064 DF frag_off:0 ttl:64 proto:17 (UDP) chk:39603
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500
Jan 14 23:54:05 firewall kernel: klips_debug:ipsec_findroute:
XX.YY.ZZ.162:500->192.168.30.99:500 17
Jan 14 23:54:05 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:96 id:26064 DF frag_off:0 ttl:64 proto:17 (UDP) chk:39603
saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500
Jan 14 23:54:05 firewall kernel: klips_debug:pfkey_address_process:
found address family=2, AF_INET, 192.168.30.99.
Jan 14 23:54:05 firewall kernel: klips_debug:pfkey_address_process:
tdb_said.dst set to 192.168.30.99.

Tom Eastep

2004-Jan-15 00:52 UTC

head link

Re: shorewall & ipsec -- zone issue?

As near as I can tell, this is standard behavior with the "cryptoAPI"
facility. And visiting the Super FreeSwan site leads me to believe that
Super FreeSwan requires cryptoAPI.

There was a post recently which dealt with this:

http://lists.shorewall.net/pipermail/shorewall-users/2003-December/010417.html

-Tom
PS -- pardon the top-post; using OE tonight...
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://www.shorewall.net
Washington USA  \ teastep@shorewall.net

----- Original Message ----- 
From: "Michael Ferraro" <mike@myvest.com>
To: <shorewall-users@lists.shorewall.net>
Sent: Wednesday, January 14, 2004 4:36 PM
Subject: Re: [Shorewall-users] shorewall & ipsec -- zone issue?

> Tom,
>
> Looking at the logs I sent along with my second-to-last message
> (reposted below), the packet is being picked up by the tunnel, being
> decrypted, de-encapsulated, and then sent to the desired host,
> 192.168.0.30 -- the one I''m trying to ICMP ping.
>
> At that point, Shorewall is seeing that the "IN" device is eth4,
as you
> pointed out.  Do you suspect the misbehavior is with the ipsec service
> or with my shorewall configuration?  Any suggestions for how I might fix
> this?
>
> Thanks,
> Mike
>
>
> Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv:
> SA:esp0xe3416e09@XX.YY.ZZ.162, src=192.168.30.99 of pkt agrees with
> expected SA source address policy.
> Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv: packet from
> 192.168.30.99 received with seq=2 (iv)=0x2d51cda1d28d7c1f iplen=112
> esplen=80 sa=esp0xe3416e09@XX.YY.ZZ.162
> Jan 14 23:54:00 firewall kernel: klips_debug:ipsec_rcv: packet decrypted
> from 192.168.30.99: next_header = 4, padding = 2
> Jan 14 23:54:00 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
> tlen:80 id:5632 frag_off:0 ttl:128 proto:4 chk:60064 saddr:192.168.30.99
> daddr:XX.YY.ZZ.162
> Jan 14 23:54:00 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
> tlen:60 id:892 frag_off:0 ttl:128 proto:1 (ICMP) chk:38771
> saddr:192.168.30.99 daddr:192.168.0.30 type:code=8:0
>
> *****
> Jan 14 23:54:00 firewall kernel: Shorewall:air2loc:DROP:IN=eth4 OUT=eth1
> SRC=192.168.30.99 DST=192.168.0.30 LEN=60 TOS=0x00 PREC=0x00 TTL=127
> ID=892 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=17408
> *****
>
> Jan 14 23:54:05 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
> tlen:96 id:26064 DF frag_off:0 ttl:64 proto:17 (UDP) chk:39603
> saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500
> Jan 14 23:54:05 firewall kernel: klips_debug:ipsec_findroute:
> XX.YY.ZZ.162:500->192.168.30.99:500 17
> Jan 14 23:54:05 firewall kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
> tlen:96 id:26064 DF frag_off:0 ttl:64 proto:17 (UDP) chk:39603
> saddr:XX.YY.ZZ.162:500 daddr:192.168.30.99:500
> Jan 14 23:54:05 firewall kernel: klips_debug:pfkey_address_process:
> found address family=2, AF_INET, 192.168.30.99.
> Jan 14 23:54:05 firewall kernel: klips_debug:pfkey_address_process:
> tdb_said.dst set to 192.168.30.99.
>
>
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm
>

Tom Eastep

2004-Jan-15 00:56 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wed, 14 Jan 2004, Tom Eastep wrote:
> As near as I can tell, this is standard behavior with the
"cryptoAPI"
> facility. And visiting the Super FreeSwan site leads me to believe that
> Super FreeSwan requires cryptoAPI.
>
> There was a post recently which dealt with this:
>
>
http://lists.shorewall.net/pipermail/shorewall-users/2003-December/010417.html
>
Note: I''m in the process of updating the Shorewall IPSEC documentation
based on David''s post. I have no way of verifying the documentation
however since I no longer use IPSEC tunnels here.

-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Holger Brueckner

2004-Jan-15 13:37 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wed, 2004-01-14 at 23:35, Michael Ferraro wrote:
> --> /etc/shorewall/interfaces:
> net     eth0            detect         
> dropunclean,routefilter,norfc1918,blacklist
> loc     eth1            detect          dropunclean
> dmz     eth2            detect          dropunclean,routeback
> dat     eth3            detect          dropunclean
> air     eth4            detect          dropunclean
> vpn     ipsec0
hmm, you did no define any broadcast adress for your vpn interface.
maybe this would result in some side effects ?

mine for example looks like this:
-       ipsec0  10.10.0.255,10.10.4.255,10.10.8.255

i think yours should be:
vpn	ipsec0	192.168.30.255

cya

Holger

Holger Brueckner

2004-Jan-15 13:41 UTC

head link

Re: shorewall & ipsec -- zone issue?

argh .. your not connecting 2 net .. my error

On Thu, 2004-01-15 at 14:37, Holger Brueckner wrote:> On Wed, 2004-01-14 at 23:35, Michael Ferraro wrote:
> 
> > --> /etc/shorewall/interfaces:
> > net     eth0            detect         
> > dropunclean,routefilter,norfc1918,blacklist
> > loc     eth1            detect          dropunclean
> > dmz     eth2            detect          dropunclean,routeback
> > dat     eth3            detect          dropunclean
> > air     eth4            detect          dropunclean
> > vpn     ipsec0
> 
> hmm, you did no define any broadcast adress for your vpn interface.
> maybe this would result in some side effects ?
> 
> mine for example looks like this:
> -       ipsec0  10.10.0.255,10.10.4.255,10.10.8.255
> 
> i think yours should be:
> vpn	ipsec0	192.168.30.255
> 
> cya
> 
> Holger
> 
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users
> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm

Holger Brueckner

2004-Jan-15 13:45 UTC

head link

Re: shorewall & ipsec -- zone issue?

another comment (maybe more usefull) :)

have you ever used tcpdump to actually see what is happening on ipsec0
device ?

baba

Holger

Holger Brueckner

2004-Jan-15 13:48 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wed, 2004-01-14 at 23:35, Michael Ferraro wrote:
> Involved interfaces:
> 
> NET ZONE
> eth0      Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
>           inet addr:<PUBLIC_IP_1>  Bcast:<PUBLIC_IP_2> 
> 	Mask:255.255.255.224
> VPN ZONE 
> ipsec0    Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
>           inet addr:<PUBLIC_IP_2>  Mask:255.255.255.224
uhh ? PUBLIC_IP_2" as broadcast on eth0 and ip on ipsec0 ?

Tom Eastep

2004-Jan-15 17:14 UTC

head link

Re: shorewall & ipsec -- zone issue?

On Wed, 2004-01-14 at 16:16, Michael Ferraro wrote:> ipsec0 is present when the ipsec service is running.
> 
> Mike
> 
> 
> 
> # ifconfig ipsec0
> ipsec0    Link encap:Ethernet  HWaddr 00:05:5D:30:08:08
>           inet addr:XX.YY.ZZ.162  Mask:255.255.255.224
>           UP RUNNING NOARP  MTU:16260  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
>           Collisions:0
>  
> 
> sid: -root-
> # svi ipsec stop
> ipsec_setup: Stopping FreeS/WAN IPsec...
>  
> sid: -root-
> # ifconfig ipsec0
> ipsec0: unknown interface.
I wonder if you are having a problem similar to what I suspect for Alex
-- outbound traffic is going through the ipsec0 interface but inbound
traffic is bypassing the tunnel? What does the routing table look like
on the remote end?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Shorewall users - Jan 2004 - shorewall & ipsec -- zone issue?

shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?

Re: shorewall & ipsec -- zone issue?