Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 5 subscribers
  • Views 1509 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 interfering with internal HTTPs traffic

terrzfor

I recently started segmentation between several old subnets. For this I have set up two subnets (10.20.40.0/24 and 10.68.161.0/24). These two subnets are separated by the UTM.

IPs are:

  • 10.68.161.1 = UTM
  • 10.68.161.2 = my server = elastic02
  • 10.20.40.24 = my workstation

Traffic coming from my workstation to the server via SSH shows no surprises:

terrzfor@elastic02 ~ % sudo tcpdump -n -i any "tcp[tcpflags] & (tcp-syn) != 0 and port 22"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode                                                                                              
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
14:49:38.303560 IP 10.20.40.24.57120 > 10.68.161.2.22: Flags [S], seq 1808819620, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0                             
14:49:38.303616 IP 10.68.161.2.22 > 10.20.40.24.57120: Flags [S.], seq 700548809, ack 1808819621, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
^C                                                                                                                                                                      
2 packets captured                             
2 packets received by filter
0 packets dropped by kernel      

 

Traffic coming from my workstation flowing to the server via HTTPs apparently gets NATted:

terrzfor@elastic02 ~ % sudo tcpdump -n -i any "tcp[tcpflags] & (tcp-syn) != 0 and port 443"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:15:53.914602 IP 10.68.161.1.41436 > 10.68.161.2.443: Flags [S], seq 3613153771, win 29200, options [mss 1460,sackOK,TS val 1029716380 ecr 0,nop,wscale 7], length 0
15:15:53.914635 IP 10.68.161.2.443 > 10.68.161.1.41436: Flags [S.], seq 4016378411, ack 3613153772, win 28960, options [mss 1460,sackOK,TS val 189142402 ecr 1029716380,nop,wscale 7], length 0
15:15:53.918097 IP 10.68.161.1.41437 > 10.68.161.2.443: Flags [S], seq 1748235087, win 29200, options [mss 1460,sackOK,TS val 1029716381 ecr 0,nop,wscale 7], length 0
15:15:53.918131 IP 10.68.161.2.443 > 10.68.161.1.41437: Flags [S.], seq 30279257, ack 1748235088, win 28960, options [mss 1460,sackOK,TS val 189142405 ecr 1029716381,nop,wscale 7], length 0
15:15:53.918294 IP 10.68.161.1.41438 > 10.68.161.2.443: Flags [S], seq 2986924860, win 29200, options [mss 1460,sackOK,TS val 1029716381 ecr 0,nop,wscale 7], length 0
15:15:53.918311 IP 10.68.161.2.443 > 10.68.161.1.41438: Flags [S.], seq 3189393017, ack 2986924861, win 28960, options [mss 1460,sackOK,TS val 189142405 ecr 1029716381,nop,wscale 7], length 0
15:16:02.249337 IP 10.68.161.1.41503 > 10.68.161.2.443: Flags [S], seq 4207280564, win 29200, options [mss 1460,sackOK,TS val 1029718464 ecr 0,nop,wscale 7], length 0
15:16:02.249366 IP 10.68.161.2.443 > 10.68.161.1.41503: Flags [S.], seq 4256262539, ack 4207280565, win 28960, options [mss 1460,sackOK,TS val 189150736 ecr 1029718464,nop,wscale 7], length 0
15:16:15.138353 IP 10.68.161.1.41542 > 10.68.161.2.443: Flags [S], seq 1753472627, win 29200, options [mss 1460,sackOK,TS val 1029721687 ecr 0,nop,wscale 7], length 0
15:16:15.138383 IP 10.68.161.2.443 > 10.68.161.1.41542: Flags [S.], seq 1184620351, ack 1753472628, win 28960, options [mss 1460,sackOK,TS val 189163625 ecr 1029721687,nop,wscale 7], length 0
15:16:15.138862 IP 10.68.161.1.41543 > 10.68.161.2.443: Flags [S], seq 167746886, win 29200, options [mss 1460,sackOK,TS val 1029721687 ecr 0,nop,wscale 7], length 0
15:16:15.138885 IP 10.68.161.2.443 > 10.68.161.1.41543: Flags [S.], seq 785051466, ack 167746887, win 28960, options [mss 1460,sackOK,TS val 189163626 ecr 1029721687,nop,wscale 7], length 0

 

 

Any ideas which setting to use to adjust that behavior?



This thread was automatically locked due to age.
Parents
  • +1

    Hi  

    If the traffic is destined for port 80 or 443 and if the source Network is listed as Allowed Networks in the Web Filter profile of UTM, it would be filtered by the WebProxy. And if the traffic is filtered by WebProxy, it will also be NATed by UTM. Please refer to Bob's RULZ guide to understand how UTM9 works and how you can troubleshoot it.

    If you would like to skip this traffic from being filtered, please add the destination network range in Web Protection > Filtering Options > Misc | Skip Transparent Mode Destination Hosts/Nets and that traffic will not be filtered by WebProxy and in turn will not be NATed by UTM. But make sure you have a Firewall rule in place to allow the traffic between these two networks.

    Regards

    Jaydeep

  • 0 in reply to Jaydeep

    Excellent, that was the culprit.

    Thanks a lot.

Reply Children
  • 0 in reply to terrzfor

    Hallo and welcome to the UTM Community!

    Jaydeep solved it for you, but you also may be interested in a document I maintain that I make available to members of the UTM Community, "Configure HTTP Proxy for a Network of Guests."  If you would like me to send you this document, PM me your email address. For our German-speaking members, I also maintain a version auf Deutsch initially translated by fellow member hallowach when he and I did a major revision in 2013.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Unfiltered HTML