Guest User!

You are not Sophos Staff.

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

UTM 9 + IPSEC tunnel only works during tcpdump; or maybe I need DMZ?

EWIT

Here's a doozy. I have an IPSEC VPN connection with a default route such that machines on the VPN subnet will "emerge" onto the Internet from the Sophos at my main office. That's perfect, and precisely what I want.

But it only works when I run tcpdump -i br0 on the Sophos! The instant I stop tcpdump, pings no longer work.

External IP on the Sophos: 200.0.0.30/27

Upstream gateway: 200.0.0.1

Bridge Interface 0 is eth1 and eth7, because eth7 is connected to a VOIP PBX device that is required to have an external public IP address, 200.0.0.6. Proxy ARP is checked (not sure why, it was recommended during setup and worked, so I haven't messed with it).

LAN is 172.21.0.0/16

VPN is 172.19.0.0/16 and is a simple IPSEC connection to AWS VPC.

Under Additional Addresses on the Sophos, I've added 200.0.0.4 and 200.0.0.6.

I have a Masquerade rule for the VPN, so machines on the 172.19.0.0/16 VPN subnet emerge from our main router at 200.0.0.4.

Here's a picture:

Without tcpdump running:

  • Ping both directions between the LAN 172.21.0.0 network and VPN 172.19.0.0 network OK
  • Ping from VPN 172.19.0.0 to LAN 172.21.1.1 OK
  • Ping from VPN to the Sophos external address 200.0.0.30 OK
  • Ping from VPN to 200.0.0.6 (the other IP in the bridge) FAIL
  • Ping from VPN to 200.0.0.1 or any other Internet address: FAIL

With tcpdump running, all pings from the VPN succeed. And it only works if I tcpdump the br0 interface.

Also notable: If I use the -p switch to disable tcpdump promiscuous mode, it doesn't work.

I'm wondering if the bridge interface is the problem, so I'm considering removing the bridge. 

Is there some way I can still have the VOIP box with its external IP address, and keep it connected to eth7? 

Any idea what tcpdump promiscuous mode does that "fixes" the problem? Would this indicate a packet filter or route problem somewhere?



This thread was automatically locked due to age.
Parents
  • 0

    "If I use the -p switch to disable tcpdump promiscuous mode, it doesn't work." I guess you have a mis-configuration of your IPsec tunnel.

    "Would this indicate a packet filter or route problem somewhere?" - Have you already followed #1 in Rulz?  That will help you answer this question.

    Please show pictures of the IPsec Connection and Remote Gateway open in Edit.

    Cheers - Bob

  • 0 in reply to BAlfson

    Thanks for helping, Bob!

    The IPsec connection looks like this:

    The Remote Gateway bits:

    Logs are not showing anything blocked on the Sophos. Everything else on the other end of the IPsec tunnel works, in that it can see our internal LAN just fine.

  • 0 in reply to EWIT

    Does either "Amazon VPC or "Amazon VPC 172.19.x.y" violate #3 in Rulz?

    Cheers - Bob

  • 0 in reply to BAlfson

    Summary, Rule 3: leave host/network definitions bound to interface Any.

    No, we're all clear there.

    BUT... Just took a look at the routes table:

    default via 200.0.0.1 dev br0  table 200  proto kernel onlink 
default via 200.0.0.1 dev br0  table default  proto kernel  metric 20 onlink 
10.28.55.0/24 dev wlan1  proto kernel  scope link  src 10.28.55.1 
10.242.2.0/24 dev tun0  proto kernel  scope link  src 10.242.2.1 
127.0.0.0/8 dev lo  scope link 
172.19.0.0/16 dev br0  proto ipsec  scope link  src 10.28.55.1 
172.20.0.0/16 dev br0  proto ipsec  scope link  src 172.21.1.1 
172.21.0.0/16 dev eth0  proto kernel  scope link  src 172.21.1.1 
172.22.3.0/24 dev reds1  proto kernel  scope link  src 172.22.3.1

    That 10.28.55.1 is the guest wifi network. And this is the only route table entry referring to the 172.19.0.0 network.

    Shouldn't this be:

    172.19.0.0/16 dev br0 proto ipsec scope link src 172.21.1.1

     

  • 0 in reply to EWIT

    Why does br0 include 172.19.0.0/16?  I thought this was the WAN interface, so this is probably the clue you needed to find the config error.

    "Is there some way I can still have the VOIP box with its external IP address, and keep it connected to eth7? "  Yes:

    1. Break the bridge.
    2. Change the netmask on eth1 to /32 (with the UTM, you don't need a subnet that includes the default gateway).
    3. Assign 200.0.0.x/32 to eth7.
    4. Create a firewall rule like 'Internet,PBX -> Any -> Internet, PBX : Allow'.

    I bet you don't really want "Any" as this is equivalent to putting a switch between eth1 and the ISP and then connecting the VoIP PBX to the switch.

    Cheers - Bob

  • 0 in reply to BAlfson

    "Why does br0 include 172.19.0.0/16?"

    Great question. According to the configuration UI, it doesn't. I have no idea why the route table thinks the IPSEC connections are bridged to the WAN.

    Thanks for the bridge splitting idea. Next step: I'm gonna break that bridge and see if the routes go sane. Wish me luck...

  • 0 in reply to BAlfson

    BAlfson said:

    Why does br0 include 172.19.0.0/16?  I thought this was the WAN interface, so this is probably the clue you needed to find the config error.

    "Is there some way I can still have the VOIP box with its external IP address, and keep it connected to eth7? "  Yes:

    1. Break the bridge.
    2. Change the netmask on eth1 to /32 (with the UTM, you don't need a subnet that includes the default gateway).
    3. Assign 200.0.0.x/32 to eth7.
    4. Create a firewall rule like 'Internet,PBX -> Any -> Internet, PBX : Allow'.

    I bet you don't really want "Any" as this is equivalent to putting a switch between eth1 and the ISP and then connecting the VoIP PBX to the switch.

    Cheers - Bob

    I'm confused at step 3 above. What's the x?

    I tried 200.0.0.7/32 (a previously unused external IP), then had to add a route to 200.0.0.6 (the VOIP box) and enable Proxy ARP. It worked for a few hours, then failed. It started working again after I poked at it a while and removed the Additional Address.

    On the plus side: eliminating the bridge means the original IPSEC tunnel problem is resolved!

    At this moment, everything seems to be working, but I've quite lost confidence that I know WHY it's working. I'll start another thread to follow up.

Reply
  • 0 in reply to BAlfson

    BAlfson said:

    Why does br0 include 172.19.0.0/16?  I thought this was the WAN interface, so this is probably the clue you needed to find the config error.

    "Is there some way I can still have the VOIP box with its external IP address, and keep it connected to eth7? "  Yes:

    1. Break the bridge.
    2. Change the netmask on eth1 to /32 (with the UTM, you don't need a subnet that includes the default gateway).
    3. Assign 200.0.0.x/32 to eth7.
    4. Create a firewall rule like 'Internet,PBX -> Any -> Internet, PBX : Allow'.

    I bet you don't really want "Any" as this is equivalent to putting a switch between eth1 and the ISP and then connecting the VoIP PBX to the switch.

    Cheers - Bob

    I'm confused at step 3 above. What's the x?

    I tried 200.0.0.7/32 (a previously unused external IP), then had to add a route to 200.0.0.6 (the VOIP box) and enable Proxy ARP. It worked for a few hours, then failed. It started working again after I poked at it a while and removed the Additional Address.

    On the plus side: eliminating the bridge means the original IPSEC tunnel problem is resolved!

    At this moment, everything seems to be working, but I've quite lost confidence that I know WHY it's working. I'll start another thread to follow up.

Children
No Data