Search Results

Search found 103 results on 5 pages for 'mss'.

Page 3/5 | < Previous Page | 1 2 3 4 5  | Next Page >

• Linux, some packets are not being NAT

  - by user70932

  Hi, I'm trying to NAT HTTP traffic, I'm new to this and facing some issues. What i'm trying to do is NAT client HTTP requests to a webserver. CLIENT - NAT BOX - WEBSERVER When the client open the IP of the NAT BOX, the request should be pass to the web server. But I'm getting "HTTP request sent, awaiting response..." and then wait serveral minutes before the request is done. Looking at the tcpdump output, it looks like the first Syn packet on (10:48:54) is being NAT but not the second, third, fourth... ACK or PSH packets, and wait until (10:52:04) it starts NAT again on the ACK packet. The iptables command I'm using is: iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 \ -j DNAT --to-destination WEBSERVER I'm wondering what could have caused this behavior? Thanks alot. 10:48:54.907861 IP (tos 0x0, ttl 49, id 16395, offset 0, flags [DF], proto: TCP (6), length: 48) CLIENT.61736 > NATBOX.http: S, cksum 0x6019 (correct), 1589600740:1589600740(0) win 5840 <mss 1460,nop,wscale 8> 10:48:54.907874 IP (tos 0x0, ttl 48, id 16395, offset 0, flags [DF], proto: TCP (6), length: 48) CLIENT.61736 > WEBSERVER.http: S, cksum 0xb5d7 (correct), 1589600740:1589600740(0) win 5840 <mss 1460,nop,wscale 8> 10:48:55.102696 IP (tos 0x0, ttl 49, id 16397, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x2727 (correct), ack 2950613896 win 23 10:48:55.102963 IP (tos 0x0, ttl 49, id 16399, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:48:58.103078 IP (tos 0x0, ttl 49, id 16401, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:48:58.366344 IP (tos 0x0, ttl 49, id 16403, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:49:04.103204 IP (tos 0x0, ttl 49, id 16405, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:49:04.363943 IP (tos 0x0, ttl 49, id 16407, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:49:16.101583 IP (tos 0x0, ttl 49, id 16409, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:49:16.363475 IP (tos 0x0, ttl 49, id 16411, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:49:40.100796 IP (tos 0x0, ttl 49, id 16413, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:49:40.563898 IP (tos 0x0, ttl 49, id 16415, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:50:28.099396 IP (tos 0x0, ttl 49, id 16417, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:50:28.761678 IP (tos 0x0, ttl 49, id 16419, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x26af (correct), ack 1 win 23 10:52:04.093668 IP (tos 0x0, ttl 49, id 16421, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > NATBOX.http: P 0:120(120) ack 1 win 23 10:52:04.093678 IP (tos 0x0, ttl 48, id 16421, offset 0, flags [DF], proto: TCP (6), length: 160) CLIENT.61736 > WEBSERVER.http: P 1589600741:1589600861(120) ack 2950613896 win 23 10:52:04.291021 IP (tos 0x0, ttl 49, id 16423, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x25d3 (correct), ack 217 win 27 10:52:04.291028 IP (tos 0x0, ttl 48, id 16423, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: ., cksum 0x7b91 (correct), ack 217 win 27 10:52:04.300708 IP (tos 0x0, ttl 49, id 16425, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x253c (correct), ack 368 win 27 10:52:04.300714 IP (tos 0x0, ttl 48, id 16425, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: ., cksum 0x7afa (correct), ack 368 win 27 10:52:04.301417 IP (tos 0x0, ttl 49, id 16427, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: F, cksum 0x253b (correct), 120:120(0) ack 368 win 27 10:52:04.301438 IP (tos 0x0, ttl 48, id 16427, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: F, cksum 0x7af9 (correct), 120:120(0) ack 368 win 27 10:52:04.498875 IP (tos 0x0, ttl 49, id 16429, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > NATBOX.http: ., cksum 0x253a (correct), ack 369 win 27 10:52:04.498881 IP (tos 0x0, ttl 48, id 16429, offset 0, flags [DF], proto: TCP (6), length: 40) CLIENT.61736 > WEBSERVER.http: ., cksum 0x7af8 (correct), ack 369 win 27

  Read the article

• tcpdump selective acknowledgements question

  - by wlaus

  Hi All, I eventually sometimes watch most initial tcp connection attempts like this: tcpdump -nn -Z somepcapuser not src host (12x.x5.109.xxx or 62.75.160.xxx ) and not (port 9001 or 443 or 8080 ) and tcp[tcpflags]&(tcp-syn) !=0 and not tcp[tcpflags]& (tcp-ack) !=0 or icmp this works pretty well to quickly identify oddness so far. However, I now have a question on the following output: 03:53:52.227884 IP 203.81.166.20.53786 62.75.160.xxx.80: S 846930886:846930886(0) win 61690 "<"mss 1460,nop,nop,sackOK,opt-178:f04700000000,nop,wscale 4"" I wonder what the marked portion means, haven't seen that before. Thanks for help wlaus

  Read the article

• My IIS server won't serve SSL sites to some browsers

  - by sbleon

  (Update: This is now cross-posted at http://stackoverflow.com/questions/3355000. This is the more appropriate forum, but StackOverflow gets a lot more traffic.) I've got an IIS 6.0 server that won't serve pages over SSL to some browsers. In Webkit-based browsers on OS X 10.6, I can't load pages at all. In MSIE 8 on Windows XP SP3, I can load pages, but it will sometimes hang downloading images or sending POSTs. Working: Firefox 3.6 (OS X + Windows) Chrome (Windows) Partially Working: MSIE 8 (works sometimes, but hangs up, especially on POSTs) Not Working: Chrome 5 (OS X) Safari 5 (OS X) Mobile Safari (iOS 4) On OS X (the easiest platform for me to test on), Chrome and Firefox both negotiate the same TLS Cipher, but Chrome hangs on or after the post-negotiation handshake. Chrome packet capture (via ssldump): 1 1 0.0485 (0.0485) C>S Handshake ClientHello Version 3.1 cipher suites Unknown value 0xc00a Unknown value 0xc009 Unknown value 0xc007 Unknown value 0xc008 Unknown value 0xc013 Unknown value 0xc014 Unknown value 0xc011 Unknown value 0xc012 Unknown value 0xc004 Unknown value 0xc005 Unknown value 0xc002 Unknown value 0xc003 Unknown value 0xc00e Unknown value 0xc00f Unknown value 0xc00c Unknown value 0xc00d Unknown value 0x2f TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 Unknown value 0x35 TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0x32 Unknown value 0x33 Unknown value 0x38 Unknown value 0x39 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA compression methods NULL 1 2 0.3106 (0.2620) S>C Handshake ServerHello Version 3.1 session_id[32]= bb 0e 00 00 7a 7e 07 50 5e 78 48 cf 43 5a f7 4d d2 ed 72 8f ff 1d 9e 74 66 74 03 b3 bb 92 8d eb cipherSuite TLS_RSA_WITH_RC4_128_MD5 compressionMethod NULL Certificate ServerHelloDone 1 3 0.3196 (0.0090) C>S Handshake ClientKeyExchange 1 4 0.3197 (0.0000) C>S ChangeCipherSpec 1 5 0.3197 (0.0000) C>S Handshake [hang, no more data transmitted] Firefox packet capture: 1 1 0.0485 (0.0485) C>S Handshake ClientHello Version 3.1 resume [32]= 14 03 00 00 4e 28 de aa da 7a 25 87 25 32 f3 a7 ae 4c 2d a0 e4 57 cc dd d7 0e d7 82 19 f7 8f b9 cipher suites Unknown value 0xff Unknown value 0xc00a Unknown value 0xc014 Unknown value 0x88 Unknown value 0x87 Unknown value 0x39 Unknown value 0x38 Unknown value 0xc00f Unknown value 0xc005 Unknown value 0x84 Unknown value 0x35 Unknown value 0xc007 Unknown value 0xc009 Unknown value 0xc011 Unknown value 0xc013 Unknown value 0x45 Unknown value 0x44 Unknown value 0x33 Unknown value 0x32 Unknown value 0xc00c Unknown value 0xc00e Unknown value 0xc002 Unknown value 0xc004 Unknown value 0x96 Unknown value 0x41 TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA Unknown value 0x2f Unknown value 0xc008 Unknown value 0xc012 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 Unknown value 0xfeff TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL 1 2 0.0983 (0.0497) S>C Handshake ServerHello Version 3.1 session_id[32]= 14 03 00 00 4e 28 de aa da 7a 25 87 25 32 f3 a7 ae 4c 2d a0 e4 57 cc dd d7 0e d7 82 19 f7 8f b9 cipherSuite TLS_RSA_WITH_RC4_128_MD5 compressionMethod NULL 1 3 0.0983 (0.0000) S>C ChangeCipherSpec 1 4 0.0983 (0.0000) S>C Handshake 1 5 0.1019 (0.0035) C>S ChangeCipherSpec 1 6 0.1019 (0.0000) C>S Handshake 1 7 0.1019 (0.0000) C>S application_data 1 8 0.2460 (0.1440) S>C application_data 1 9 0.3108 (0.0648) S>C application_data 1 10 0.3650 (0.0542) S>C application_data 1 11 0.4188 (0.0537) S>C application_data 1 12 0.4580 (0.0392) S>C application_data 1 13 0.4831 (0.0251) S>C application_data [etc] Update: Here's a Wireshark capture from the server end. What's going on with those two much-delayed RST packets? Is that just IIS terminating what it perceives as a non-responsive connection? 19 10.129450 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=699250189 TSER=0 20 10.129517 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 21 10.168596 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=699250189 TSER=0 22 10.172950 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Client Hello 23 10.173267 10.100.xxx.xx 67.249.xxx.xxx TCP [TCP segment of a reassembled PDU] 24 10.173297 10.100.xxx.xx 67.249.xxx.xxx TCP [TCP segment of a reassembled PDU] 25 10.385180 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=148 Ack=2897 Win=524280 Len=0 TSV=699250191 TSER=163006 26 10.385235 10.100.xxx.xx 67.249.xxx.xxx TLSv1 Server Hello, Certificate, Server Hello Done 27 10.424682 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=148 Ack=4215 Win=524280 Len=0 TSV=699250192 TSER=163008 28 10.435245 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Client Key Exchange 29 10.438522 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Change Cipher Spec 30 10.438553 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [ACK] Seq=4215 Ack=421 Win=65115 Len=0 TSV=163008 TSER=699250192 31 10.449036 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Encrypted Handshake Message 32 10.580652 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [ACK] Seq=4215 Ack=458 Win=65078 Len=0 TSV=163010 TSER=699250192 7312 57.315338 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50644 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 19531 142.316425 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [RST, ACK] Seq=4215 Ack=458 Win=0 Len=0

  Read the article

• LDAP over SSL with an EFI Fiery printer

  - by austinian

  I've got a printer with a Fiery running 8e Release 2. I can authenticate users against AD using the LDAP configuration, but I can only get it to work if I don't use SSL/TLS, and only if I use SIMPLE authentication. Right now, it's authenticating using a fairly low-impact user, but it's also the only system on our network that's not using LDAPS. I can get AD info fine over LDAPS using ldp.exe from my machine, our firewall, our mail filter, our linux boxes, etc. The only problem child is the Fiery. I've added the LDAP server certificate as a trusted cert to the Fiery, but after I check the box for Secure Communication and change the port to 636, pressing Validate results in a dialog box coming up saying: LDAP Validation Failed Server Name invalid or server is unavailable. I've tried changing the server name to use just the name, the FQDN, and the IP address, and changed it to another server, just to see if it was just this AD server that was fussy with the Fiery. EDIT: removed LDP output, added packet capture analysis from wireshark: The conversation seems pretty normal to me, up to the point where the Fiery terminates the connection after the server sends back a handshake response. Maybe they messed up their TLS implementation? I'm trying support, but it's been fairly useless so far. The cert is a SHA-2 (sha256RSA) 2048-bit certificate. Also, it looks like the Fiery is specifying TLS 1.0. Looking at http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx, I'm not seeing SHA256 and TLS 1.0 combination being supported by SChannel. headdesk perhaps that's why, after the DC changes the cipher spec, the connection is terminated by the Fiery? TLS 1.1 and 1.2 are enabled on the DC. Wireshark conversation: DC: 172.17.2.22, Fiery: 172.17.2.42 No. Time Source Source Port Destination Destination Port Protocol Length Info 1 0.000000000 172.17.2.42 48633 172.17.2.22 ldaps TCP 74 48633 > ldaps [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3101761 TSecr=0 WS=4 2 0.000182000 Dell_5e:94:e3 Broadcast ARP 60 Who has 172.17.2.42? Tell 172.17.2.22 3 0.000369000 TyanComp_c9:0f:90 Dell_5e:94:e3 ARP 60 172.17.2.42 is at 00:e0:81:c9:0f:90 4 0.000370000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 74 ldaps > 48633 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=67970573 TSecr=3101761 5 0.000548000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=3101761 TSecr=67970573 6 0.001000000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 147 Client Hello 7 0.001326000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU] 8 0.001513000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU] 9 0.001515000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=1449 Win=8736 Len=0 TSval=3101761 TSecr=67970573 10 0.001516000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=2897 Win=11632 Len=0 TSval=3101761 TSecr=67970573 11 0.001732000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU] 12 0.001737000 172.17.2.22 ldaps 172.17.2.42 48633 TLSv1 1243 Server Hello, Certificate, Certificate Request, Server Hello Done 13 0.001738000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=4345 Win=14528 Len=0 TSval=3101761 TSecr=67970573 14 0.001739000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=5522 Win=17424 Len=0 TSval=3101761 TSecr=67970573 15 0.002906000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 78 Certificate 16 0.004155000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 333 Client Key Exchange 17 0.004338000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5522 Ack=361 Win=66304 Len=0 TSval=67970573 TSecr=3101762 18 0.004338000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 72 Change Cipher Spec 19 0.005481000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 327 Encrypted Handshake Message 20 0.005645000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5522 Ack=628 Win=66048 Len=0 TSval=67970574 TSecr=3101762 21 0.010247000 172.17.2.22 ldaps 172.17.2.42 48633 TLSv1 125 Change Cipher Spec, Encrypted Handshake Message 22 0.016451000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [FIN, ACK] Seq=628 Ack=5581 Win=17424 Len=0 TSval=3101765 TSecr=67970574 23 0.016630000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5581 Ack=629 Win=66048 Len=0 TSval=67970575 TSecr=3101765 24 0.016811000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 60 ldaps > 48633 [RST, ACK] Seq=5581 Ack=629 Win=0 Len=0

  Read the article

• Permanent Routes Centos Questions

  - by user65053

  So with a little help I figured out how to setup these routes and I can set them in rc.local route add -net 208.82.236.0 netmask 255.255.255.0 dev ppp0 metric 1 route add -net 208.82.236.0 netmask 255.255.255.0 dev eth0 metric 10 my question is being that the first route is ppp0 as soon as I disconnect the modem the route is dropped how do I maintain the route or make it permanent so that next time the modem connects it will follow the route. Currently after ppp0 disconnects the route is dropped netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface laxapx03.o1.com * 255.255.255.255 UH 0 0 0 ppp0 208.82.236.0 * 255.255.255.0 U 0 0 0 eth0 10.0.1.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 10.0.1.1 0.0.0.0 UG 0 0 0 eth0

  Read the article

• W2k8 RC1: Windows Media Servers (WMS) as proxy

  - by da_didi

  (fullquote from stackoverflow.com/questions/2690788/w2k8-rc1-windows-media-servers-wms-as-proxy/2690791#2690791) I will have one streaming-server (W2k8, unknown streaming protocol [rtsp, mss, http]) and half dozen streaming-servers as proxies to save bandwidth. I have read the documentation and installed the modules, but I am unsure how I have to configure the proxy's according to http://technet.microsoft.com/de-de/library/ee126142(en-us,WS.10).aspx - as a proxy or reverse proxy and how I minimize the bandwidth needs between origin server and proxy's. What is the best way to realize my setup? Any short how-tos? How can I announce all players to use the proxy? Route all rtsp/mms/http-requests through my proxy? Announce the proxy with DHCP-releases? Thanks!

  Read the article

• SSH not working over IPSec tunnel (Strongswan)

  - by PattPatel

  I configured a small network on a cloud virtual machine. This virtual machine has a static IP address assigned to eth0 interface that I'll call $EXTIP. mydomain.com points to $EXTIP. Inside, I have some linux containers, that get their ip through DHCP in the Subnet 10.0.0.0/24 (i called the virtual interface nat ). They run some services that can be reached through DNAT. Then I wanted to connect to these containers through an IPSec tunnel, so I configured StrongSwan. ipsec.conf: conn %default dpdaction=none rekey=no conn remote keyexchange=ikev2 ike=######## left=[$EXTIP] leftsubnet=10.0.1.0/24,10.0.0.0/24 leftauth=pubkey lefthostaccess=yes leftcert=########.pem leftfirewall=yes leftid="#########" right=%any rightsourceip=10.0.1.0/24 rightauth=######## rightid=%any rightsendcert=never eap_identity=%any auto=add type=tunnel Everything works fine, IPSec clients get IPs of the 10.0.1.0/24 subnet and can reach the containers subnet. My problem is that I'm not able to get SSH connections over the tunnel. It simply does not work, ssh client does not produce any output. Sniffing with tcpdump gives: tcpdump: 09:50:29.648206 ARP, Request who-has 10.0.0.1 tell mydomain.com, length 28 09:50:29.648246 ARP, Reply 10.0.0.1 is-at 00:ff:aa:00:00:01 (oui Unknown), length 28 09:50:29.648253 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [S], seq 4007849772, win 29200, options [mss 1460,sackOK,TS val 1151153 ecr 0,nop,wscale 7], length 0 09:50:29.648296 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [S.], seq 2809522632, ack 4007849773, win 14480, options [mss 1460,sackOK,TS val 11482992 ecr 1151153,nop,wscale 6], length 0 09:50:29.677225 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 2809522633, win 229, options [nop,nop,TS val 1151162 ecr 11482992], length 0 09:50:29.679370 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [P.], seq 0:23, ack 1, win 229, options [nop,nop,TS val 1151162 ecr 11482992], length 23 09:50:29.679403 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], ack 24, win 227, options [nop,nop,TS val 11483002 ecr 1151162], length 0 09:50:29.684337 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1:32, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 31 09:50:29.685471 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 32:1480, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 1448 09:50:29.685519 IP mydomain.com > 10.0.0.1: ICMP mydomain.com unreachable - need to frag (mtu 1422), length 556 09:50:29.685567 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 32:1402, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 1370 09:50:29.685572 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 1402:1480, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 78 09:50:29.714601 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 32, win 229, options [nop,nop,TS val 1151173 ecr 11483003], length 0 09:50:29.714642 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1480:1600, ack 24, win 227, options [nop,nop,TS val 11483012 ecr 1151173], length 120 09:50:29.723649 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [P.], seq 1393:1959, ack 32, win 229, options [nop,nop,TS val 1151174 ecr 11483003], length 566 09:50:29.723677 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], ack 24, win 227, options [nop,nop,TS val 11483015 ecr 1151173,nop,nop,sack 1 {1394:1960}], length 0 09:50:29.725688 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 1480, win 251, options [nop,nop,TS val 1151177 ecr 11483003], length 0 09:50:29.952394 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1480:1600, ack 24, win 227, options [nop,nop,TS val 11483084 ecr 1151173,nop,nop,sack 1 {1394:1960}], length 120 09:50:29.981056 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 1600, win 251, options [nop,nop,TS val 1151253 ecr 11483084,nop,nop,sack 1 {1480:1600}], length 0 If you need it this is my iptables configuration file: iptables: *filter :INPUT ACCEPT [144:9669] :FORWARD DROP [0:0] :OUTPUT ACCEPT [97:15649] :interfacce-trusted - [0:0] :porte-trusted - [0:0] -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j interfacce-trusted -A FORWARD -j porte-trusted -A FORWARD -j REJECT --reject-with icmp-host-unreachable -A FORWARD -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 10.0.0.3/32 -p tcp -m tcp --dport 1234 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A interfacce-trusted -i nat -j ACCEPT -A porte-trusted -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -j ACCEPT -A porte-trusted -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -j ACCEPT -A porte-trusted -d 10.0.0.3/32 -p tcp -m tcp --dport 1234 -j ACCEPT COMMIT *nat :PREROUTING ACCEPT [10:600] :INPUT ACCEPT [10:600] :OUTPUT ACCEPT [4:268] :POSTROUTING ACCEPT [18:1108] -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80 -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1:443 -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 8069 -j DNAT --to-destination 10.0.0.3:1234 -A POSTROUTING -s 10.0.0.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT -A POSTROUTING -s 10.0.1.0/24 -o nat -j MASQUERADE -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE COMMIT Probably I'm missing something stupid... Thanks in advance for helping :))

  Read the article

• How do I force a specific MTU for only certain TCP ports?

  - by Dave S.

  Background I have a set of embedded hardware deployed in the field. These remote machines connect back to my servers at AWS running Ubuntu and I use the iptables mangle chain to lower the MTU to 500 so these devices are happy. For reference, this is the iptables rule I am using: -A POSTROUTING -p tcp --sport 12345 --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss 500 Current Problem I'm trying to spin up some servers on the Joyent Cloud using SmartOS, but I can't find any information on selectively changing the MTU like I can on Linux (e.g. all info I've found is on changing it globally, which is not what I want). How would I do it so that all connections on TCP port 12345 get the MTU I want?

  Read the article

• How to set which IP to use for a HTTP request?

  - by GetFree

  This is probably a silly question. I'm doing some http requests using wget from the command line, and I want those connections to be made through one specific IP of the 4 IPs my server has. Those http requests go to one specific range of IPs so I only want those to be routed differently. The 4 interfaces in my server are eth0, eth0:0, eth0:1, eth0:2. I tried with the following command: route add -net 192.164.10.0/24 dev eth0:0 But when I see the routing table it says: Destination Gateway Genmask Flags MSS Window irtt Iface 192.164.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 The interface is set to eth0 not eth0:0 as my command says. What am I doing wrong?

  Read the article

• Spambot Infection Detection

  - by crankshaft

  My server has been blocked by CBL for participating in curtwail spambot. Initially we suspected that it was coming from a PC and not from the server, but the router is blocking all packets on 25 except those coming from the server. I have just executed the tcpdump command and every 5 minutes I see a flurry of activity on port 25 that is very suspicious and I am sure that there is some process running on the server: 13:02:30.027436 IP exprod5og110.obsmtp.com.53803 > ubuntu.local.smtp: Flags [S], seq 171708781, win 5744, options [mss 1436,sackOK,TS val 3046699707 ecr 0,nop,wscale 2], length 0 I have stopped postfix, and yet there is still traffic on port 25 above. But how can I find what process is actually communicating on port 25 as it only rund for a few seconds and so for example lsof -i :25 will never catch it. I have been working on this now for 2 days, it is a live server and I cannot simply shut it down, any suggestion on how I can detect the source of this email bot process ?

  Read the article

• Host is unreacheble with static networking configuration via /etc/network/interfaces while GUI NetworkManager is ok

  - by Riccardo

  I have some trouble setting-up the network interface using the static IP configuration. I run ubuntu 12.04 kernel 3.11.0-22 with the back-ports enabled. I followed these instructions from help.ubuntu.com but there seems to exist some conflict between the GUI approach (NetworkManager) and the command line approach. $ sudo nano /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.1.1.50 gateway 10.1.1.10 netmask 255.255.255.0 dns-nameservers 192.168.3.45 192.168.8.10 $ sudo /etc/init.d/networking restart I than try to ping for example google.com ping -c 3 www.google.com the response is that the host is unreachable. The icon on the top right of the desktop says: wired network disconnected. If I work using the GUI approach (Edit Connections and so on...) all works great. Can same one explain to me where I wrong? $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 90:e6:ba:07:4a:77 inet addr:10.1.1.50 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::92e6:baff:fe07:4a77/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39619 errors:0 dropped:0 overruns:0 frame:0 TX packets:18520 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:19030895 (19.0 MB) TX bytes:2768769 (2.7 MB) $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

  Read the article

• W2k8 RC1: Windows Media Servers (WMS) as proxy

  - by da_didi

  I will have one streaming-server (W2k8, unknown streaming protocol [rtsp, mss, http]) and half dozen streaming-servers as proxies to save bandwidth. I have read the documentation and installed the modules, but I am unsure how I have to configure the proxy's according to http://technet.microsoft.com/de-de/library/ee126142(en-us,WS.10).aspx - as a proxy or reverse proxy and how I minimize the bandwidth needs between origin server and proxy's. What is the best way to realize my setup? Any short how-tos? How can I announce all players to use the proxy? Route all rtsp/mms/http-requests through my proxy? Announce the proxy with DHCP-releases? Thanks!

  Read the article

• How do i get the default gateway in LINUX given the destination?

  - by Suezy

  Good day! I'm trying to get the default gateway, using the destination 0.0.0.0 i used this command: netstat -rn | grep 0.0.0.0 and it returns this list: Destination Gateway Genmask Flags MSS Window irtt Iface 10.9.9.17 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 133.88.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 133.88.31.70 0.0.0.0 UG 0 0 0 eth0 My goal here is to ping the default gateway using destination 0.0.0.0; thus, that is "133.88.31.70"; but this one returns a list because of using 'grep'. Question is: How do i get the default gateway only? I will need it for my bash script to identify if net connection is up or not. Any answers will be much appreciated. =)

  Read the article

• Application stuck in TCP retransmit

  - by SandeepJ

  I am running Linux kernel 3.13 (Ubuntu 14.04) on two Virtual Machines each of which operates inside two different servers running ESXi 5.1. There is a zeromq client-server application running between the two VMs. After running for about 10-30 minutes, this application consistently hangs due to inability to retransmit a lost packet. When I run the same setup over Ubuntu 12.04 (Linux 3.11), the application never fails If you notice below, "ss" (socket statistics) shows 1 packet lost, sk_wmem_queued of 14110 (i.e. w14110) and a high rto (120000). State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 12350 192.168.2.122:41808 192.168.2.172:55550 timer:(on,16sec,10) uid:1000 ino:35042 sk:ffff880035bcb100 <- skmem:(r0,rb648720,t0,tb1164800,f2274,w14110,o0,bl0) ts sack cubic wscale:7,7 rto:120000 rtt:7.5/3 ato:40 mss:8948 cwnd:1 ssthresh:21 send 9.5Mbps unacked:1 retrans:1/10 lost:1 rcv_rtt:1476 rcv_space:37621 Since this has happened so consistently, I was able to capture the TCP log in wireshark. I found that the packet which is lost does get retransmitted and even acknowledged by the TCP in the other OS (the sequence number is seen in the ACK), but the sender doesn't seem to understand this ACK and continues retransmitting. MTU is 9000 on both virtual machines and througout the route. The packets being sent are large in size. As I said earlier, this does not happen on Ubuntu 12.04 (kernel 3.11). So I did a diff on the TCP config options (seen via "sysctl -a |grep tcp ") between 14.04 and 12.04 and found the following differences. I also noticed that net.ipv4.tcp_mtu_probing=0 in both configurations. Left side is 3.11, right side is 3.13 <<net.ipv4.tcp_abc = 0 <<net.ipv4.tcp_cookie_size = 0 <<net.ipv4.tcp_dma_copybreak = 4096 14c11 << net.ipv4.tcp_early_retrans = 2 --- >> net.ipv4.tcp_early_retrans = 3 17c14 << net.ipv4.tcp_fastopen = 0 >> net.ipv4.tcp_fastopen = 1 20d16 << net.ipv4.tcp_frto_response = 0 26,27c22 << net.ipv4.tcp_max_orphans = 16384 << net.ipv4.tcp_max_ssthresh = 0 >> net.ipv4.tcp_max_orphans = 4096 29,30c24,25 << net.ipv4.tcp_max_tw_buckets = 16384 << net.ipv4.tcp_mem = 94377 125837 188754 >> net.ipv4.tcp_max_tw_buckets = 4096 >> net.ipv4.tcp_mem = 23352 31138 46704 34a30 >> net.ipv4.tcp_notsent_lowat = -1 My question to the networking experts on this forum : Are there any other debugging tools or options I can install/enable to dig further into why this TCP retransmit failure is occurring so consistently ? Are there any configuration changes which might account for this weird behaviour.

  Read the article

• xt_TCPMSS: bad length messages

  - by Matic

  I'm getting loads of messages like: Jun 23 10:24:20 awakening kernel: [ 1691.596823] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663362] xt_TCPMSS: bad length (1448 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663495] xt_TCPMSS: bad length (1448 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663588] xt_TCPMSS: bad length (1448 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663671] xt_TCPMSS: bad length (1440 bytes) Jun 23 10:24:26 awakening kernel: [ 1697.062914] xt_TCPMSS: bad length (474 bytes) Jun 23 10:24:26 awakening kernel: [ 1697.305525] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:27 awakening kernel: [ 1698.946633] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:36 awakening kernel: [ 1707.481198] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:37 awakening kernel: [ 1708.723526] xt_TCPMSS: bad length (805 bytes) Jun 23 10:24:38 awakening kernel: [ 1709.599461] xt_TCPMSS: bad length (805 bytes) Jun 23 10:24:41 awakening kernel: [ 1712.211052] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:41 awakening kernel: [ 1712.260588] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:41 awakening kernel: [ 1712.976058] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:43 awakening kernel: [ 1714.225209] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:43 awakening kernel: [ 1714.914961] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:55 awakening kernel: [ 1726.192696] xt_TCPMSS: bad length (1480 bytes) Jun 23 10:24:55 awakening kernel: [ 1726.192825] xt_TCPMSS: bad length (1480 bytes) In my dmesg/syslog. This linux machine is among other things used as an internet gateway. Connection is over PPPoE. I have the following line in my iptables script: $IPT -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu # PPPoE fix The frequency of this messages increased 10x when I upgraded from Debian lenny with 2.6.27 to squeeze with 2.6.32 few days ago. Why am I seeing this messages and how can I fix them?

  Read the article

• SSL / HTTP / No Response to Curl

  - by Alex McHale

  I am trying to send commands to a SOAP service, and getting nothing in reply. The SOAP service is at a completely separate site from either server I am testing with. I have written a dummy script with the SOAP XML embedded. When I run it at my local site, on any of three machines -- OSX, Ubuntu, or CentOS 5.3 -- it completes successfully with a good response. I then sent the script to our public host at Slicehost, where I fail to get the response back from the SOAP service. It accepts the TCP socket and proceeds with the SSL handshake. I do not however receive any valid HTTP response. This is the case whether I use my script or curl on the command line. I have rewritten the script using SOAP4R, Net::HTTP and Curb. All of which work at my local site, none of which work at the Slicehost site. I have tried to assemble the CentOS box as closely to match my Slicehost server as possible. I rebuilt the Slice to be a stock CentOS 5.3 and stock CentOS 5.4 with the same results. When I look at a tcpdump of the bad sessions on Slicehost, I see my script or curl send the XML to the remote server, and nothing comes back. When I look at the tcpdump at my local site, I see the response just fine. I have entirely disabled iptables on the Slice. Does anyone have any ideas what could be causing these results? Please let me know what additional information I can furnish. Thank you! Below is a wire trace of a sample session. The IP that starts with 173 is my server while the IP that starts with 12 is the SOAP server's. No. Time Source Destination Protocol Info 1 0.000000 173.45.x.x 12.36.x.x TCP 36872 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=137633469 TSER=0 WS=6 Frame 1 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 2 0.040000 12.36.x.x 173.45.x.x TCP https > 36872 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460 Frame 2 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 3 0.040000 173.45.x.x 12.36.x.x TCP 36872 > https [ACK] Seq=1 Ack=1 Win=5840 Len=0 Frame 3 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 4 0.050000 173.45.x.x 12.36.x.x SSLv2 Client Hello Frame 4 (156 bytes on wire, 156 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 1, Ack: 1, Len: 102 Secure Socket Layer No. Time Source Destination Protocol Info 5 0.130000 12.36.x.x 173.45.x.x TCP [TCP segment of a reassembled PDU] Frame 5 (1434 bytes on wire, 1434 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 1, Ack: 103, Len: 1380 Secure Socket Layer No. Time Source Destination Protocol Info 6 0.130000 173.45.x.x 12.36.x.x TCP 36872 > https [ACK] Seq=103 Ack=1381 Win=8280 Len=0 Frame 6 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 103, Ack: 1381, Len: 0 No. Time Source Destination Protocol Info 7 0.130000 12.36.x.x 173.45.x.x TLSv1 Server Hello, Certificate, Server Hello Done Frame 7 (1280 bytes on wire, 1280 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 1381, Ack: 103, Len: 1226 [Reassembled TCP Segments (2606 bytes): #5(1380), #7(1226)] Secure Socket Layer No. Time Source Destination Protocol Info 8 0.130000 173.45.x.x 12.36.x.x TCP 36872 > https [ACK] Seq=103 Ack=2607 Win=11040 Len=0 Frame 8 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 103, Ack: 2607, Len: 0 No. Time Source Destination Protocol Info 9 0.130000 173.45.x.x 12.36.x.x TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message Frame 9 (236 bytes on wire, 236 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 103, Ack: 2607, Len: 182 Secure Socket Layer No. Time Source Destination Protocol Info 10 0.190000 12.36.x.x 173.45.x.x TLSv1 Change Cipher Spec, Encrypted Handshake Message Frame 10 (97 bytes on wire, 97 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 2607, Ack: 285, Len: 43 Secure Socket Layer No. Time Source Destination Protocol Info 11 0.190000 173.45.x.x 12.36.x.x TLSv1 Application Data Frame 11 (347 bytes on wire, 347 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 285, Ack: 2650, Len: 293 Secure Socket Layer No. Time Source Destination Protocol Info 12 0.190000 173.45.x.x 12.36.x.x TCP [TCP segment of a reassembled PDU] Frame 12 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 13 0.450000 12.36.x.x 173.45.x.x TCP https > 36872 [ACK] Seq=2650 Ack=578 Win=64958 Len=0 Frame 13 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 2650, Ack: 578, Len: 0 No. Time Source Destination Protocol Info 14 0.450000 173.45.x.x 12.36.x.x TCP [TCP segment of a reassembled PDU] Frame 14 (206 bytes on wire, 206 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 2038, Ack: 2650, Len: 152 No. Time Source Destination Protocol Info 15 0.510000 12.36.x.x 173.45.x.x TCP [TCP Dup ACK 13#1] https > 36872 [ACK] Seq=2650 Ack=578 Win=64958 Len=0 Frame 15 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Dell_fb:49:a1 (00:21:9b:fb:49:a1), Dst: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6) Internet Protocol, Src: 12.36.x.x (12.36.x.x), Dst: 173.45.x.x (173.45.x.x) Transmission Control Protocol, Src Port: https (443), Dst Port: 36872 (36872), Seq: 2650, Ack: 578, Len: 0 No. Time Source Destination Protocol Info 16 0.850000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 16 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 17 1.650000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 17 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 18 3.250000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 18 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer No. Time Source Destination Protocol Info 19 6.450000 173.45.x.x 12.36.x.x TCP [TCP Retransmission] [TCP segment of a reassembled PDU] Frame 19 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 40:40:17:3a:f4:e6 (40:40:17:3a:f4:e6), Dst: Dell_fb:49:a1 (00:21:9b:fb:49:a1) Internet Protocol, Src: 173.45.x.x (173.45.x.x), Dst: 12.36.x.x (12.36.x.x) Transmission Control Protocol, Src Port: 36872 (36872), Dst Port: https (443), Seq: 578, Ack: 2650, Len: 1460 Secure Socket Layer

  Read the article

• Secondary IP (eth0:0) acts like main server IP

  - by George Tasioulis

  I have a CentOS server, configured with 4 consecutive IPs: eth0 5.x.x.251 eth0:0 5.x.x.252 eth0:1 5.x.x.253 eth0:2 5.x.x.254 The problem is that all traffic goes out to the internet with eth0:0 (5.x.x.252) as the source IP, instead of eth0. # curl ifconfig.me 5.x.x.252 How can I fix this, so that all traffic goes out via eth0, ie my main IP? PS: My server is VPS running on a Xen dom0, the latter being configured in routed mode networking. Thanks in advance! Server configuration # ifconfig eth0 Link encap:Ethernet HWaddr 00:x:x:x:x:AE inet addr:5.x.x.251 Bcast:5.x.x.255 Mask:255.255.255.255 inet6 addr: fe80::x:x:x:x/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14675569 errors:0 dropped:0 overruns:0 frame:0 TX packets:9463227 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4122016502 (3.8 GiB) TX bytes:25959110751 (24.1 GiB) Interrupt:23 eth0:0 Link encap:Ethernet HWaddr 00:x:x:x:x:AE inet addr:5.x.x.252 Bcast:5.x.x.255 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:23 eth0:1 Link encap:Ethernet HWaddr 00:x:x:x:x:AE inet addr:5.x.x.253 Bcast:5.x.x.255 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:23 eth0:2 Link encap:Ethernet HWaddr 00:x:x:x:x:AE inet addr:5.x.x.254 Bcast:5.x.x.255 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:23 # cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 5.x.x.251 [fqdn] [hostname] # cat ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=yes IPADDR=5.x.x.251 NETMASK=255.255.255.224 SCOPE="peer 5.x.y.82" # cat ifcfg-eth0:0 DEVICE=eth0:0 BOOTPROTO=static ONBOOT=yes IPADDR=5.x.x.252 NETMASK=255.255.255.224 # cat route-eth0 ADDRESS0=0.0.0.0 NETMASK0=0.0.0.0 GATEWAY0=5.x.y.82 # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 5.x.y.82 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 5.x.x.224 0.0.0.0 255.255.255.224 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 5.x.y.82 0.0.0.0 UG 0 0 0 eth0

  Read the article

• multiple ip for a server not reachable

  - by andrewk

  FYI: I've read everything on Serverfault related to this question and have faced a different issue. Simply put, I've got one server (apache2) with couple of sites on it. It currently has 1 ip. I'm trying to assign/add another ip to that server, so I can give each site a different ip for ssl purposes. I am not lucking out. The new ip simply is unreachable, I've pinged it. This is what I've got below, what am I doing wrong. auto lo iface lo inet loopback auto eth0 eth0:0 eth0:1 iface eth0 inet static address 70.116.5.244 netmask 255.255.255.0 gateway 70.116.5.1 #THE NEW IP iface eth0:0 inet static address 26.175.217.102 netmask 255.255.255.0 #PRIVATE IP iface eth0:1 inet static address 192.168.158.88 netmask 255.255.128.0 NOTE: THESE IP'S ARE TWEAKED BUT RELATIVE I've read many questions here 90% similar to this but most actually have the IP respond, not this case. Thanks netstar -r output Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface default gw-u6.linode.co 0.0.0.0 UG 0 0 0 eth0 70.116.5.0 * 255.255.255.0 U 0 0 0 eth0 26.175.217.0 * 255.255.255.0 U 0 0 0 eth0 192.168.128.0 * 255.255.128.0 U 0 0 0 eth0

  Read the article

• Unable to Access Certain Websites

  - by codejoust

  Through a local network, all computers except one ubuntu machine can access 1. Adobe.com 2. Icann.org 3. Apache.org 4. Example.com. The ubuntu machine returns (in firefox): "Though the site seems valid, the browser was unable to establish a connection." Furthermore, when I traceroute those websites using the ubuntu machine, they all return ubuntu.local, and it ends there: (traceroute to icann.org (192.0.32.7), 30 hops max, 40 byte packets 1 ubuntu.local (192.168.1.105) 3000.791 ms !H 3000.808 ms !H 3000.814 ms !H I've checked the hosts file, and there isn't anything in there, and I have an apache server there so if it was redirected to localhost, I'd probably see the localhost webroot page. Thanks in advance! user@ubuntu:~$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 192.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1 The Ubuntu Machine is one of six on the network. I'm using opendns for dns, so I do think that should be a problem.

  Read the article

• xt_TCPMSS: bad length messages

  - by Matic

  Hey! I'm getting loads of messages like: Jun 23 10:24:20 awakening kernel: [ 1691.596823] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663362] xt_TCPMSS: bad length (1448 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663495] xt_TCPMSS: bad length (1448 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663588] xt_TCPMSS: bad length (1448 bytes) Jun 23 10:24:21 awakening kernel: [ 1692.663671] xt_TCPMSS: bad length (1440 bytes) Jun 23 10:24:26 awakening kernel: [ 1697.062914] xt_TCPMSS: bad length (474 bytes) Jun 23 10:24:26 awakening kernel: [ 1697.305525] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:27 awakening kernel: [ 1698.946633] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:36 awakening kernel: [ 1707.481198] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:37 awakening kernel: [ 1708.723526] xt_TCPMSS: bad length (805 bytes) Jun 23 10:24:38 awakening kernel: [ 1709.599461] xt_TCPMSS: bad length (805 bytes) Jun 23 10:24:41 awakening kernel: [ 1712.211052] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:41 awakening kernel: [ 1712.260588] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:41 awakening kernel: [ 1712.976058] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:43 awakening kernel: [ 1714.225209] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:43 awakening kernel: [ 1714.914961] xt_TCPMSS: bad length (1492 bytes) Jun 23 10:24:55 awakening kernel: [ 1726.192696] xt_TCPMSS: bad length (1480 bytes) Jun 23 10:24:55 awakening kernel: [ 1726.192825] xt_TCPMSS: bad length (1480 bytes) In my dmesg/syslog. This linux machine is among other things used as an internet gateway. Connection is over PPPoE. I have the following line in my iptables script: $IPT -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu # PPPoE fix The frequency of this messages increased 10x when I upgraded from Debian lenny with 2.6.27 to squeeze with 2.6.32 few days ago. Why am I seeing this messages and how can I fix them?

  Read the article

• Natting trafic from a tunnel to internet

  - by mezgani

  I'm trying to set up a GRE tunnel between a linux box and a router (LAN), and I'm having a few problems which seem to depend to my iptables configuration. Watching with tcpdump on linux box, I can see packets coming with flags GREv0, all i need right know is forwarding this data to internet, found here some trace : iptables -F iptables -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -t nat -F iptables -t nat -X iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P OUTPUT ACCEPT iptables -t mangle -F iptables -t mangle -X iptables -t mangle -P PREROUTING ACCEPT iptables -t mangle -P OUTPUT ACCEPT iptables -A INPUT -p 47 -j ACCEPT iptables -A FORWARD -i ppp0 -o cloud -j ACCEPT iptables -A FORWARD -i cloud -o ppp0 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE echo "1" /proc/sys/net/ipv4/ip_forward cloud Link encap:UNSPEC HWaddr C4-CE-7A-2E-F2-BF-DD-C0-00-00-00-00-00-00-00-00 inet adr:10.3.3.3 P-t-P:10.3.3.3 Masque:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:124 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:0 (0.0 B) TX bytes:10416 (10.1 KiB) Table de routage IP du noyau Destination Passerelle Genmask Indic MSS Fenêtre irtt Iface 196.206.120.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.3.3.0 0.0.0.0 255.255.255.0 U 0 0 0 cloud 0.0.0.0 196.206.120.1 0.0.0.0 UG 0 0 0 ppp0 root@aldebaran:~# ip route 196.206.120.1 dev ppp0 proto kernel scope link src 196.206.122.46 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.18 10.3.3.0/24 dev cloud scope link default via 196.206.120.1 dev ppp0

  Read the article

• Bypassing SQUID on freebsd with PF

  - by epema

  I have PF+SQUID31 on FREEBSD-9.0, and I want to have some hosts(aka goodguys) to bypass the proxy, so that torrents are not logged. Also, I am not sure about transparent. It means that I dont have to configure proxy settings on the client side right? I have tried doing a redirect no rdr on $int_if inet proto {tcp,udp} from 192.168.1.233/32 to any However, no luck :( Here is a quick look of my conf files: SQUID /usr/local/etc/squid/squid.conf http_port 192.168.1.1:8080 transparent RC /etc/rc.conf: gateway_enable="YES" pf_enable="YES" pf_rules="/usr/local/etc/pf.conf" pflog_enable="YES" squid_enable="YES" I have squid31 installed from ports with SQUID_PF "Enable transparent proxying with PF" on PF /usr/loca/etc/pf.conf: int_if="re0" ext_if="bge0" localnet="{ 192.168.1.0/24 }" table <goodguys> const { "192.168.1.219", "192.168.1.233" } set block-policy drop set skip on lo0 scrub in all fragment reassemble scrub out all random-id max-mss 1440 block in on $ext_if pass out on $ext_if keep state block in on $int_if pass in on $int_if inet proto tcp from $int_if:network to $int_if port 8080 keep state pass in on $int_if inet proto udp from $int_if:network to $int_if port 21 keep state pass in on $int_if inet proto udp from $int_if:network to $int_if port 22 keep state pass in on $int_if inet proto udp from $int_if:network to $int_if port 53 keep state pass in on $int_if inet proto tcp from $int_if:network to any port { smtp, pop3 } keep state pass in on $int_if inet proto icmp from $int_if:network to $int_if keep state pass out on $int_if keep state What lines should I add in conf files? I am assuming that the problem is on the firewall(pf).

  Read the article

• How is it possible that I can do a host lookup but not a curl?

  - by Daniel Quinn

  Has anyone ever seen this before? Note that this happens not only with google.com, but with every domain I try. It's a wireless connection (WEP), but I'm not sure how that would be relevant: $ curl -v google.com # This takes about 60s to return * getaddrinfo(3) failed for google.com:80 * Couldn't resolve host 'google.com' * Closing connection #0 curl: (6) Couldn't resolve host 'google.com' $ host google.com google.com has address 209.85.148.106 google.com has address 209.85.148.147 google.com has address 209.85.148.99 google.com has address 209.85.148.103 google.com has address 209.85.148.104 google.com has address 209.85.148.105 google.com mail is handled by 30 alt2.aspmx.l.google.com. google.com mail is handled by 40 alt3.aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com. google.com mail is handled by 10 aspmx.l.google.com. google.com mail is handled by 20 alt1.aspmx.l.google.com. $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.1.201 $ cat /etc/hosts 127.0.0.1 localhost ::1 localhost $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 wlan0 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

  Read the article

• Debian can't connect to internet using LAN

  - by tampe125

  I have a headless Raspberry Pi using Debian Wheezy. I have a wifi dongle and if I connect my Raspberry using it, everything works fine: I can connect to the Internet, I can ping, I can update. However, if I get down my wifi and set up the lan interface, I lost my internet connection. I still can connect locally, using my laptop, but the connection doesn't exit (ie ping is not working). Some useful info: cat /etc/network/interfaces auto lo auto eth0 iface eth0 inet static address 192.168.0.105 netmask 255.255.255.0 gateway 192.168.0.1 ping www.google.com (nothing request timed out) ifconfig eth0 Link encap:Ethernet HWaddr b8:27:eb:a2:b5:20 inet addr:192.168.0.105 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1130 errors:0 dropped:0 overruns:0 frame:0 TX packets:1116 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:97223 (94.9 KiB) TX bytes:146140 (142.7 KiB) ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. ^C --- 192.168.0.1 ping statistics --- 19 packets transmitted, 0 received, 100% packet loss, time 18007ms cat /etc/resolv.conf nameserver 8.8.8.8 netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 well, I think that's all... Any ideas?

  Read the article

• Debian can't connect to internet using LAN

  - by tampe125

  I have a headless Raspberry Pi using Debian Wheezy. I have a wifi dongle and if I connect my Raspberry using it, everything works fine: I can connect to the Internet, I can ping, I can update. However, if I get down my wifi and set up the lan interface, I lost my internet connection. I still can connect to it locally, using my laptop, but the connection doesn't exit (ie ping is not working). Some useful info: cat /etc/network/interfaces auto lo auto eth0 iface eth0 inet static address 192.168.0.105 netmask 255.255.255.0 gateway 192.168.0.1 ping www.google.com (nothing request timed out) ifconfig eth0 Link encap:Ethernet HWaddr b8:27:eb:a2:b5:20 inet addr:192.168.0.105 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1130 errors:0 dropped:0 overruns:0 frame:0 TX packets:1116 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:97223 (94.9 KiB) TX bytes:146140 (142.7 KiB) ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. ^C --- 192.168.0.1 ping statistics --- 19 packets transmitted, 0 received, 100% packet loss, time 18007ms cat /etc/resolv.conf nameserver 8.8.8.8 netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 well, I think that's all... Any ideas?

  Read the article

< Previous Page | 1 2 3 4 5  | Next Page >