Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 2 subscribers
  • Views 3222 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange Behaviour after Publishing Web Site

yassin
Hi every one. 
I have Astarto 7.200, I published an internal web site, by adding an IP address to the external interface, DNAT the same to the DMZ server, and created backet filter rules. 
The publishing worked fine, however I have an IPsec site-to-site VPN (with NAT-T) stopped immediately after this publishing.More over I have a BlackBerry server lost connection to outside world as well. Other web servers are OK.

Here are some log enteries:
********************************************************
IPSEC Log:

2008:09:02-13:12:50 (none) ipsec_starter[3954]: Starting strongSwan IPsec 2.7.3 [starter]...

2008:09:02-13:12:50 (none) ipsec_starter[3966]: old index 0, new index 4, if=eth2

2008:09:02-13:12:50 (none) ipsec_starter[3966]: interface or IP address changed -> reinit of ipsec interface

2008:09:02-13:12:50 (none) pluto[3976]: Starting Pluto (strongSwan Version 2.7.3 THREADS LIBCURL LDAP_V3 VENDORID XAUTH_VID KEYRR)

2008:09:02-13:12:50 (none) pluto[3976]:   including NAT-Traversal patch (Version 0.6c)
-----------------------------------------------
2008:09:02-13:13:20 (none) pluto[3976]: packet from Y.Y.Y.Y:60149: ignoring Vendor ID payload [strongSwan 2.7.3]

2008:09:02-13:13:20 (none) pluto[3976]: packet from Y.Y.Y.Y:60149: ignoring Vendor ID payload [XAUTH]

2008:09:02-13:13:20 (none) pluto[3976]: packet from Y.Y.Y.Y:60149: received Vendor ID payload [Dead Peer Detection]

2008:09:02-13:13:20 (none) pluto[3976]: packet from Y.Y.Y.Y:60149: received Vendor ID payload [RFC 3947]

2008:09:02-13:13:20 (none) pluto[3976]: packet from Y.Y.Y.Y:60149: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]

2008:09:02-13:13:20 (none) pluto[3976]: packet from Y.Y.Y.Y:60149: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]

2008:09:02-13:13:20 (none) pluto[3976]: packet from Y.Y.Y.Y:60149: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]

2008:09:02-13:13:20 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60149 #2: responding to Main Mode from unknown peer Y.Y.Y.Y:60149

2008:09:02-13:13:21 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60149 #2: NAT-Traversal: Result using RFC 3947: peer is NATed
2008:09:02-13:13:21 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60149 #2: Peer ID is ID_DER_ASN1_DN: 'C=xx, L=xx, O=xx, CN=xx
2008:09:02-13:13:21 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60149 #2: crl not found

2008:09:02-13:13:21 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60149 #2: certificate status unknown

2008:09:02-13:13:21 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60149 #2: we have a cert and are sending it 
2008:09:02-13:13:21 (none) pluto[3976]: | NAT-T: new mapping Y.Y.Y.Y:60149/60826)

2008:09:02-13:13:21 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60826 #2: sent MR3, ISAKMP SA established

2008:09:02-13:13:21 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60826 #3: responding to Quick Mode

2008:09:02-13:13:22 (none) pluto[3976]: "S_REF_cDICljCDzI_0"[1] Y.Y.Y.Y:60826 #4: responding to Quick Mode
2008:09:02-13:13:22 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60826 #3: Dead Peer Detection (RFC 3706) enabled

2008:09:02-13:13:22 (none) pluto[3976]: "S_REF_cDICljCDzI_1"[1] Y.Y.Y.Y:60826 #3: IPsec SA established {ESP=>0x1f622ded 0x1f622dee Kernel Log:

2008:09:03-13:03:01 (none) kernel: net_enable_timestamp [named]: netstamp_needed=13

2008:09:03-13:03:02 (none) kernel: net_disable_timestamp [named]: netstamp_needed=12

2008:09:03-13:03:09 (none) kernel: device eth0 left promiscuous mode

2008:09:03-13:03:16 (none) kernel: device eth0 entered promiscuous mode

2008:09:03-13:03:16 (none) kernel: device eth0 left promiscuous mode

2008:09:03-13:03:16 (none) kernel: device eth0 entered promiscuous mode

2008:09:03-13:03:19 (none) kernel: tg3: eth1: Link is down.

2008:09:03-13:03:19 (none) kernel: tg3: eth0: Link is down.

2008:09:03-13:03:21 (none) kernel: e1000: eth2: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX

2008:09:03-13:03:22 (none) kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.

2008:09:03-13:03:22 (none) kernel: tg3: eth0: Flow control is on for TX and on for RX.

2008:09:03-13:03:23 (none) kernel: tg3: eth1: Link is up at 1000 Mbps, full duplex.

2008:09:03-13:03:23 (none) kernel: tg3: eth1: Flow control is on for TX and on for RX.

2008:09:03-13:14:40 (none) kernel: IPSEC EVENT: KLIPS device ipsec0 shut down.

2008:09:03-14:12:48 (none) kernel: net_enable_timestamp [named]: netstamp_needed=13

2008:09:03-14:12:48 (none) kernel: net_disable_timestamp [named]: netstamp_needed=12

2008:09:03-15:07:49 (none) kernel: net_disable_timestamp [named]: netstamp_needed=11

2008:09:03-15:07:56 (none) kernel: device eth0 left promiscuous mode

2008:09:03-15:08:03 (none) kernel: device eth0 entered promiscuous mode

2008:09:03-15:08:03 (none) kernel: device eth0 left promiscuous mode

2008:09:03-15:08:03 (none) kernel: device eth0 entered promiscuous mode

2008:09:03-16:12:48 (none) kernel: net_enable_timestamp [named]: netstamp_needed=12
*****************************************************

Packet Filter Log:

2008:09:03-00:00:47 (none) ulogd[2719]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth2" dstmac="***x" srcmac="yyy" srcip="Y.Y.Y.Y" dstip="x.x.x.x" proto="17" length="248" tos="0x00" prec="0x00" ttl="52" srcport="60826" dstport="4500" 


Thanks

Yassin


This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to Jack Daniel
    Dear Jack:
    Yes the DNAT is configured as external>http>dmz. By the way the published site is working fine, it is accessible from outside; the problem in the VPN site-to-site IPSec connection, it is getting disconnected immediately after adding the additional IP address, even before configuring the DNAT.
    More over PPTP client-to-site is working fine also.

    Thanks for you attention.

    Cordially,
    Yassin
Children
  • 0 in reply to yassin
    Are you sure you don't have an IP address conflict?
  • 0 in reply to BAlfson
    Hi BAlfson
    There is no IP conflict, actually we have 16 public IP addresses from our ISP, and I picked one which is not used.

    Thanks
  • 0 in reply to yassin
    My apologies for being so brief.  I meant a conflict between the internal IP of the new webserver and the address-space of the VPN.
  • 0 in reply to BAlfson
    Dear BAlfson:
    There is no confilict between the VPN and the DMZ IP addresses, the first is in 10 range and the later is in 192.168 range.
    Actually as I mentioned before, the problem occurs before configuring the NAT rule; it happens immediately after adding the new IP address to the external interface. I kept a continous bing to a host in the remote site, and I add the new IP address, when I apply this, the ping get timed out immediately. Also the published site work properly.
    Is there anything need to be done while configuring an additional IP address?

    Thanks
  • 0 in reply to yassin
    I'm sorry to be so persistant about this, but it just "feels" like an IP-conflict.

    Is there a conflict between your 192.168 range and the IP subnet of the internal network of the site VPNing into your network?
  • 0 in reply to BAlfson
    The VPN site local IP addresses is in 10.x.x.x range, while the DMZ servers is in 192.168.x.x range. No IP conflict in this regard. 
    Just to clear your doubts in this area; we have more than 6 servers in the DMZ published in the same way and they are working fine. More over the problem occurs before creating the DNAT rule. Just adding a new IP address to the external interface will create this problem.

    Best Regards,
    Yassin
  • 0 in reply to yassin
    It sounds like you have reviewed the config pretty thoroughly, but let me toss out a few more ideas:

    Is the IP address used in any definition besides the additional address?

    Is there another additional IP defined in such a way that it overlaps with the one in question?  (addl IP not defined as /32)

    DNAT or PF rules defined with host or network definitions which may conflict?

    It may be time to open a support case.
  • 0 in reply to Jack Daniel
    Hi jack:
    Is the IP address used in any definition besides the additional address?

    No, as I said just adding the address will creat the problem immediately, before performing any other task. I tested this by keeping a continous ping through the VPN before adding the IP address; the ping timeout immediately after adding the IP address.

    Is there another additional IP defined in such a way that it overlaps with the one in question? (addl IP not defined as /32)

    Yes, there are four IP addresses defined as /28. We have IP addresses from 112 to 127.  115 is the default for the public interface, 120, 126,117,118 are defined as /28.  I added 121 as /32 and this caused the problem. I will change all additional addresses to /32 and check again. Actually I am new to my company and to Astaro as a product, I have no clue about the existing configuration.

    DNAT or PF rules defined with host or network definitions which may conflict?

    No definition or PF rules conflict.


    Thanks for the inputs