Skip to contentSkip to conversation

ipsec connection problems though netfilter.

DISCUSSION Martin Cheatle 2 participants 2 messages Jun 10, 2007 – Jun 12, 2007

lore
Share & tools
lore
#0 lore raw

My Network

              internet
                 |
     +----------------------+
     |                      |
    eth2                    |
     |                      |
 Firewall-eth1-----netB----ISA
     |
    eth0
     |
    netA

Firewall Rules
iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 'external ip address' iptables -A FORWARD -i eth0 -o eth2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

MS/ISA Server listening for ipsec/l2tp on both adapters

My Problem

If I connect a MS/XP client to the MS/ISA server via ipsec/l2tp directly from netB or the internet every thing works fine. If I try to connect from netA through to netB the client fails to connect.
If try to connect from netA to the MS/ISA server via the internet address all works ok.

The only difference in my rules is that the traffic gets NAT'ed on the way out to the internet. I have tried NATing the traffic leaving the firewall on eth1 but this did not resolve the issue. I have added -m state rules from eth0 to eth1 and back, this did not help.

The only difference I have seen in the traffic between the connections through the firewall is a ip-fragment between netA and netB during the isakmp stage of the connection both then procced to start ESP traffic.

Has anyone seen this type of problem before?

Eventually I do want to remove the ISA server of the internet and route the ipsec/l2tp traffic through the firewall but I can't do that until i can get this bit working.

Thanks in advance
Martin

#1 lore raw

Martin:

If the only difference is a fragmentation issue you may want try one of two paths:

(a) Allow fragmented packets to pass the firewall -not a good option
(b) Reduce the mtu size of the packets in the device that generates packets with a size greater than the mtu value.

By the way, ask your question in the openswan mailing list.

Hope this helps,

Jorge Davila.

Quoted 35 lines · On Sun, 10 Jun 2007 14:05:41 +0100 Martin Cheatle <[email protected]>…

My Network

              internet
                 |
     +----------------------+
     |                      |
    eth2                    |
     |                      |
 Firewall-eth1-----netB----ISA
     |
    eth0
     |
    netA

Firewall Rules
iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 'external ip address' iptables -A FORWARD -i eth0 -o eth2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

MS/ISA Server listening for ipsec/l2tp on both adapters

My Problem

If I connect a MS/XP client to the MS/ISA server via ipsec/l2tp directly from netB or the internet every thing works fine. If I try to connect from netA through to netB the client fails to connect.
If try to connect from netA to the MS/ISA server via the internet address all works ok.

The only difference in my rules is that the traffic gets NAT'ed on the way out to the internet. I have tried NATing the traffic leaving the firewall on eth1 but this did not resolve the issue. I have added -m state rules from eth0 to eth1 and back, this did not help.

Quoted 10 lines

The only difference I have seen in the traffic between the connections through the firewall is a ip-fragment between netA and netB during the isakmp stage of the connection both then procced to start ESP traffic.

Has anyone seen this type of problem before?

Eventually I do want to remove the ISA server of the internet and route the ipsec/l2tp traffic through the firewall but I can't do that until i can get this bit working.

Thanks in advance
Martin

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
[email protected]