Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 2 subscribers
  • Views 6682 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

IPSec Issues

CWanamaker
A server located at 10.12.101.194 is trying to connect via IPSec 50/51 to 10.12.103.151. We can ping and trace from .194 to .151 without a problem. We can also connect via FTP, SSL and other ports/protocols without an issue. However, whenever we try to connect via IPSec 50/51, it doesn't work

We've added a NO NAT rule for all traffic from .194 to .151 on the UTM 10.12.101.252. We have also added an ANY > ANY > ANY Firewall rule. Still no luck.

When we try the IPSec connection, we aren't seeing anything getting blocked in the firewall. Any suggestions on what to look for or change?

** A network diagram has been attached **


This thread was automatically locked due to age.
  • 0
    Hi, what do the IPSEC logs show?

    Barry
  • 0 in reply to BarryG
    Nothing. Logs are 0 bytes. This isn't a Site-2-Site VPN but rather, one server trying to send data to another server via IPSec.
  • 0
    one server trying to send data to another server via IPSec

    You might try what I call Rule #1 (enhanced):

    Whenever something seems strange, always check the Intrusion Prevention,
    Application Control and Firewall logs.


    With IPsec, I worry about traffic being perceived as a UDP Flood.

    Any luck?

    Cheers - Bob
  • 0 in reply to BAlfson
    Already been there. We have everything in the UTM turned off except for one Firewall rule (ANY > ANY > ANY). When a test is conducted from the main server (.194), we don't see a single packet on the firewall log - passed or dropped.
  • 0
    We have everything in the UTM turned off 

    Just because Intrusion Prevention is disabled doesn't mean that Anti-DoS Flooding is disabled.  If the VPN endpoints are configured correctly, this is my last, best guess.  After that, it's time for tcpdump.

    Good luck!

    Cheers - Bob
  • 0 in reply to BAlfson
    We don't have a VPN between the Sophos UTM boxes. The VPN is handled by Verizon.

    I also checked the IPS and IPS Status is OFF, Use TCP SYN Flood Protection is unchecked, Use UDP Flood Protection is unchecked and it is the same for ICMP Flood Protection.
  • 0
    By the way, welcome to the User BB!

    Now, it seems like a routing issue.  A look at 40 lines out of the IPsec log (with debugging off) on either VPN endpoint might give some clues.  Also, please [Go Advanced] below and attach pictures of the edits of the IPsec Connection and Remote Gateway from the same endpoint UTM.

    Also, please say if the 120 and 320 are in the same building - that is to say that there's no WAN connection between them.  And confirm that, prior to this, you've been looking at logs in the 320 instead of either 120.

    Cheers - Bob
  • 0
    Bob - Thanks for the welcome!

    Unfortunately, being super new to Sophos, I have no idea where to look for the last two items. The IPSec log is empty - 0 bytes. Just to clarify, I am not having an issue with IPSec between firewalls - I am having an issue with IPSec between servers behind the firewalls
  • 0
    You have a non-trivial network topology, so I suspect there is a routing problem in the network.  Also, IPsec will reject an IPsec packet if the source of the packet is different from the encrypted sending IP in the packet - it takes some customizing to connect two devices that are behind NATting routers.

    The diagram in post #1 implies that the VPN enpoints are UTM 120 appliances, not servers - could you clarify?

    If we can't look at the IPsec log from one of the VPN endpoints, and we can't see the VPN configuration from that endpoint, the only thing left is a packet capture on the UTM interfaces to see if the traffic ever gets there and if it leaves - which I suspect it doesn't.  Do you have a tool for that?  If not, you can use tcpdump from the command line, WinSCP in Windows to copy the file off and WireShark in Windows to analyze the file.

    Cheers - Bob
  • 0 in reply to BAlfson
    How about this. We added a NO NAT rule for traffic coming from the destination network and everything worked!